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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
