Sorry for the late reply. :) Dirk Reiners wrote: > 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). > I see, and it makes good sense for development. However, as we ship apps that are a bit more 'productish', it makes more sense for us to detect errors, report reason and shut down if the rendering will be incorrect. Our users (and even our support staff sometimes) are often little helped by a funky looking screen image.
For myself, I'd like to have both, of course. :) Sometimes I really wish I could get a good error message rather than a black screen, although the latter is definately more helpful than a crash. :) I think the whole thing is about the error system serving different needs. So one needs to wear a different hat when looking at the problem of application errors. I realize that implementing support for these "commerical" demands might not be top-priority, but I'd like to discuss it to see what your thoughts/plans/reasons are. I mean, it's acceptable if you decide to reply: "Yup, sure, sound good, you need it? you do it!". :-) We first need to figure out if there is a solution to this problem that is acceptable to all. > 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. > Yeah. I think it's actually pretty ok as a logging system. Being able to selectively choose loglevels might be a good thing, but it's mostly the use of it that is my gripe, not it's implementation. > >> 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. > Yup. I was thinking of a user callback taking a event/error-struct describing the error. Then it could log/throw/Abort depending on the type of error. >> 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 > Quite nice. My only gripe is that there should error/warning similar to compiler error levels. Error is a user error: you did something wrong and it will not look very good. A warning is just telling you that it might not be efficient or something is being done that you should be aware of. My main gripe is that both shader errors and warnings are logged as warnings. I'd like to be able to discriminate here. Also, something above warning but below fatal (i.e. error) is quite nice for something that won't cause a crash, but is clearly not correct and definately the user's (i.e. my) fault. Unsupported extensions, etc. Such things. > DEBUGs are completely compiled out in release libs, i.e. zero overhead, which > is > something that was important to me. > Yup. It's very nice. >> - 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. > If you use the RAII (resource acquisition is initialization) idiom (i.e. boost::scoped_ptr for 99% of cases) then you're pretty safe. In our app we use exceptions quite a lot but only for user errors, so they are not thrown during successful runs and in case of errors we usually report something and shut down. I suppose we are leaking some memory (since we don't check for cycles in ref-ptr-chains) but it's pretty good to have It would of course be troublesome to undo a lot of state changes if you catch an error pretty late, so you could just make that a fatal one, if you can't check for it early. > >> - 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? > I list some these below. Classifying errors on type in addition to severity might also be nice, i.e. "invalid argument" for null ptrs or subchild-ing the wrong node, "invalid gl op" or "unsupported gl op" for graphics stuff, etc. Some of these I would report to my users as "internal error, please report bug to developers" while others would be "graphics error, please check driver version or call our support team". >> 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? > I'm not sure. I think it's only reasonable to add them in addition and replace them over time. Perhaps one also want's to log more specifiic data and then do a callback with shorter info. I'm mainly after the ability to know explicitly when something bad happens, rather than try to parse the log. (Since OpenSG, currently, gives me warnings here and there but still runs ok.) >> - 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. > Hence the need for different types of log-objects. Errors during graph traversal would definately benefit from a node-stack. Chunk-activation would also need something more, a back-pointer to the offending chunk's state? Cheers, /Marcus ------------------------------------------------------------------------- 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
