Hi Mathias, > I think that exception messages are not made for end users.
As already said, this might be the fundamental point of disagreement between us :) > Usually > errors and exceptions in programs must be interpreted, put into a > context and "translated" before they can be presented to users. While > presenting "raw" exception messages to users might work in some cases, > it won't in the majority of situation where exceptions happen. And > especially it doesn't work in case of i/o errors. If an error happens > while e.g. a temporary file is written that is just an intermediate step > in a process, it won't help the user to tell him what happened. Okay, I see your point here. In Base's code, this is usually solved by chaining exceptions, where a high-level layer throws an own exception describing what happened, and chaining the caught lower-level exception. Admittedly, uno.Exception misses sdbc.SQLException's cool chaining feature :) On the other hand: The translation you describe rarely happens, and nonetheless the exceptions *are* displayed to the user. My favorite example still is the Basic IDE, which you can get easily into displaying "NoSuchElementException" or "IOException" without any further info, which is of no help at all to script developer (which happens to be the end user here). > OTOH if > this is a very rare case that is hard to reproduce, it would be great to > have more developer related information that can be reported or > automatically sent in an error report. > > Exceptions are diagnostic tools for developers, and they either can > convert them into messages shown to the user (if possible) or handle > them in other ways, perhaps by throwing another exception. Enriching the > diagnostic message with information that helps developers is very > useful, and so adding file names and line numbers would be a relief. > Whether it can be logged in a file, in a report or in a "details window" > is of minor importance. Assuming you add file/line to the exception messages. How will users see it, so they can tell you? Either, they explicitly need to switch on some "generate additional developer diagnostic information" feature - which is what logging thrown exceptions would also allow, and which you say you do not want to require, 'cause of the nondeterministic bugs. Or, the "developer diagnostic information" is _always_ presented to the user, also to the ones not encountering your nondeterministic bugs, who are not interested in sending you the info. Which I continue to consider a big usability problem (slaying end users with developer babbling). > I wouldn't call this a hack. Depends on the intended semantics of Exception.Message. In your interpretation, it might be valid to transport file/line it it. In my interpretation, this would be a hack, since Message is intended for the "real" message, which would need to be separated from the file/line info. By the way, this separation is highly error-prone, and this is one reason why I call the solution a hack: If you mix file/line with "other" message content, how will you separate it? If you do not mix it, how will you determine for a given message that it's file/line info? In both cases, how do you *reliably* do this, even for exceptions thrown in third-party components (and passed to your interaction handler)? Too many uncertainties for my taste. IMO, if you need file/line info, use some dedicated file/line info channel. Do not rededicate something which by luck already exists, but was not (canonical) intended for this purpose. (This rededication of something "luckily already there and not used otherwise" is another point why I call this a hack. And continue to do so, sorry.) > So before you can call something a hack, you should present a realistic, > cleaner solution that fulfills the same requirements. So: how can we get > better diagnostic information in the case of bugs that are hard to > reproduce and where we just know that an exception has been thrown > somewhere in the code. 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.) Then, in your code where you throw an exception, log it to this logger. (Currently, loggers always re-create their log file in a new OOo session, but this can be adjusted, of course.) Now if somebody tells you about an error which needs to be diagnosed, tell him to send you the log file. Or even to only look at the last few lines of the log file, and tell you what's written there. This solution shouldn't add too much overhead, assuming that exceptions are, well, exceptional events, and logging itself isn't too expensive. > 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. 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 ... 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? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
