Frank Schönheit - Sun Microsystems Germany wrote: > When we talk about seldom, hard to reproduce errors, then let's > introduce a logger which is permanently switched ON, or at least > switched ON for log levels >= LogLevel.SEVERE. (by default, loggers are > OFF, i.e. do not log any event, regardless of the LogLevel.)
Everything that must be switched on doesn't help - if an error is hard to reproduce it usually would be gone after switching on the logger after the fact. OTOH, if we had logged the necessary information as part of the exception, the user could save or send it and help us fixing the problem. >> Mikhail's suggestion is not meant to be a replacement for our >> suboptimal error handling! > > But it imposes additional restrictions on a future somewhat-more-optimal > solution, thus making it more difficult to design/implement, thus making > it even more unlikely (than today) to ever happen. No, it just adds something that can be removed later easily. It does not impose any design constraints on other solutions, especially it does not influence any designs for a better error handling (as it is no real error handling at all). > For instance, by putting file/line into the exception message, we will > close the door for putting other meaningful information into > Exception.Message, because in two years from now on, some people will > say that adding other content will break the file/line info feature ... Sorry, I can't take that serious. I don't care for what people will say in a few years, in fact adding line/file information can be removed easily again and it does not prevent adding other stuff in the future. Sure, if you want, you can call it a stopgap solution (that's not the same as a hack!). If you are so interested in getting the "real thing", just do it! ;-) But please remember: the most important feature for us is that it must be something that doesn't need "activation". If you needed to switch it on, it's too late for those problems we intend to attack. > Without having the bigger picture how good error handling should look > like, how can we know the suggested solution will fit into this bigger > picture, instead of preventing it? As I wrote, this is not about error handling (IMHO a user centric design), it is about "user level debugging assistance" ( ULDA[TM] ;-)), the stuff you need desperately if things go haywire and you don't have a clue. So far I don't see any reason not to follow Mikhail's suggestion. At least in all projects except "dba". ;-) Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[email protected]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
