Frank Schönheit - Sun Microsystems Germany wrote: > Hi Mikhail, > >> My intention was to allow user provide the developer with information >> that identifies the source of the error. > > That's understood. > >> It would be useful in case of >> problems that appear once a year, and look to be mysterious from the >> first view. >> >> "Ugly" is a taste-related comment, so it is hard to argument for/against >> it. As for error prone transportation, a screenshot solves this problem >> easily. > > The "error-prone" (and also the "ugly", but let's omit that :) related > to something else: When you transport the file/line information via the > error message, then you need to strip it before you actually display the > message to the user. I would consider this an essential requirement, > from a user experience point of view. > > While it is helpful to you as a developer when somebody gives you a > screeshot reading "Access denied. foobar.cxx, line 134", it is certainly > not at all helpful for the average end user who does not intend to send > you the screen shot, but is happy with the "Access denied" message > already. Moreover, it is not only "not helpful", it will definitely > (IMO) alienate the average end user.
I think that exception messages are not made for end users. 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. 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. I wouldn't call this a hack. A hack is a somewhat dodgy solution for something that could be implemented in a cleaner way. And - as we are developers creating a product, not people in an acedemic discussion - it should be possible to implement it in an acceptable time frame. 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. Mikhail's suggestion is not meant to be a replacement for our suboptimal error handling! 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 "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
