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
