On Wed, 12 Feb 2003 10:50:25 -0500, Shapira, Yoav wrote: > >Howdy, >Since you asked for suggestions / comments...
Thanks. >I don't like this design approach. Crashes should be reproducible. If >your program crashes, run it again at a higher debug level. Ideally yes. But in the real word not all crashes are reproducible and users are often dumb enough not to be able tell you what they did :(. Moreover stack traces are often not enough to find the real cause of the problem. Also, the program is deployed at various clients who are not familiar with computing at all. So we're looking for ways to gather more information without any user intervention. >An appender or other structure to hold all the LoggingEvents until a >crash (which may never happen) can grow to consume huge amounts of >memory. Moreover, in the event of crash outputting all the data in this >structure could take a long time, thereby delaying your "crash". I meant a rolling buffer that would keep only the latest say 1000 logs in memory and rotate them if needed. That will neither add too much overhead for memory usage, nor will slow the program considerably. >And what more, how do you guarantee that all errors are caught by your >FatalError class? For example, do you catch internal VM errors? >OutOfMemoryErrors? The first kind is always fatal and requires a very >sophisticated trap to catch, if it's at all possible. The second kind >can be fatal and you can try to catch it and recover, but it's tricky at >best. In neither of this cases will your buffer structure help at all, >as it won't be able to output anything. Around 97% of the crashes comes from our FatalError class. We're looking for a solution for the majority of the crashes. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
