Re: [Opensg-users] RFC: Error handling

[Dirk R. <dre...@ia...>]

	Hi All,

The whole continue-running-if-possible was done somewhat on purpose under the 
motivation that a somewhat wrong picture is better than a crash or abort (which 
would happen for exceptions).

Marcus Lindblom wrote:
> 
> For other libs, Boost had a log library for review a few months ago but 
> it didn't pass. The best I could find was this comparison: 
> http://log4cpp.hora-obscura.de/index.php/LoggingLibraryForCpp. I haven't 
> looked at anyone of these too closely.

Some of the features look a little overkill for our case (telnet appender? :). 
Our goal with the OpenSG logging was to keep it small and simple. It's gotten a 
little bigger than expected, and not of its features have been used/realized 
(module-based logging being my primary gripe), but it has worked farily well so far.

> Have exception throwing optional is probably the best solution. A 
> user-callback for errors would solve this easily, as it would allow 
> anyone to throw an exception back through OpenSG code and get a proper 
> call-stack. (or just log it, or terminate the application, or send an 
> e-maill, or make some toast, or ... :)

Hm, I don't know a user callback would be equivalent to exception throwing, as 
the user callback would have to have a way to identify what kind of exception to 
throw. Being able to have different kinds and catching only certain kinds is one 
of the big advantages of exceptions.

> So, in theory, we could detect whether OpenSG logs any errors/fatals and 
> do something from the log-callback, but:
>  - Some real (IMO) errors are reported only as warnings.

My logic in assigning levels was:

FATAL: the program will likely crash if you continue
WARNING: the program will not do what you want, but it will not crash
NOTICE: something hapenned that you should know about, but the program will do 
what you expected
INFO: something you might want to know about if you're curious
DEBUG: something you need to know if you're hunting bugs

DEBUGs are completely compiled out in release libs, i.e. zero overhead, which is 
something that was important to me.

>  - A log-ouput isn't as clear in the code as a 'onError()' call.
>      - It could be hard to identify exactly where the error is (since 
> the log is just a bunch of lines)

True.

>      - It's potentially unsafe to throw an exception from the log 
> (resource leaks, unfinished log message, etc.)

Absolutely. From what I understand that's the main gripe with expcetions, it's 
nearly impossible to ensure no resource leaks. How much of a problem that is in 
practice I don't know, I haven't used exceptions productively.

>  - The logging is just text-line based. (Just level & message, not very 
> structured info.)

What other info would you be interested in? Do you have an example of what you 
were thinking of?

> The easiest way would probably be to fix the first thing, as it would 
> solve the immediate problem.
> 
>  For the other two:
>  - Add osgError() / osgFatalError() functions with user callbacks? 

You mean instead of the existing log callbacks or in addition to them?

>  - Add more info (__FUNC__, __LINE__, type?, node/core-ptr?, 
> attachment-object-name?, ip?, action-node-stack?)

__FUNC__ and __LINE__ I can see easily, the rest I'm not sure how to make it 
generic.

> Also, for exception safety, there are some manual new/delete's here and 
> there that needs replacing with std::auto_ptr or boost::scoped_ptr, but 
> that's a minor issue.

True.

	Dirk