There are good reasons for the parser to terminate in case of severe errors. If it would continue, you would end up with dangling pointers and consequences you would not like! ;-)
Sure - it's sensible for the parser to terminate - perhaps setting a flag so that any further attempt to use the library routines would fail.
But it's a stage more drastic to issue an "exit" - so that the whole application will terminate immediately. It's then got no chance to tidy up and save any internal state, pop up a dialog box to report the error back to the user, offer to work with numeric OIDs instead, or however else the programmer wishes to handle this.
So: First fix the first module before running your application with the next one.
That's (unnecessarily) restricting the application IMO. What if the application was a batch-mode SMI validator - whose whole *purpose* was to report back errors in the module - perhaps running as a network service? Is it really sensible for it to exit completely when it comes across a corrupt MIB?
A library is perfectly entitled to signal a serious error, and refuse to proceed. But it shouldn't take it upon itself to terminate the whole application.
Dave
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.