Hi Frank,
On 02/26/09 09:20, Frank Schönheit wrote:
As much as I agree that error handling needs to be improved, I don't
like the idea to "pollute" exception messages with information about the
file where the exception happened. This information should be separated
from the mere message, since the latter is (potentially) to be shown to
the user, but the former usually isn't.
But perhaps I get you wrong here, since you also talk about a "details"
window provided by the InteractionHandler, which would imply that either
the handler needs to strip the error location from the message (ugly and
error prone), or that you want to transport the location by other means
than by appending it to the message.
My intention was to allow user provide the developer with information
that identifies the source of the error. 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.
In case of exceptions that have no arguments ( and we have many of such
cases ),
Shouldn't we change those exceptions to actually *contain* a message?
And, more important, teach ourself to *not* throw exceptions which do
not contain a message?
If our exceptions had a message, it would be easy to search for the
message in our code base, and find the place where it is thrown.
By the way, the rework would take much more time, than the script adding
the lines. From this point of view, it is better to let the script run
and have at least the line numbers in the messages, than to dream how we
change all the extensions in our office.
Anyway, I have nothing against adding messages to all the exceptions, if
we have resources to do it. I see no conflict between those two tasks.
But even if all of them have messages ( thousands of unique messages? ),
the filename and linenumber will stay the best unique identifier, as
actually assertions prove.
As said above, exception messages are often displayed to end users
(imagine Basic scripts), so I always strongly disliked the "throw
FooException()" places, since this results in "FooException." being
displayed to the end user, which is in no way helpful, and simply a
usability bug.
So, to make it short: We should provide meaningful error messages when
throwing exceptions, this would solve the problem, too, in an even
broader context.
Completely agree, we should. But again, I would not mix those two
solutions..
http://wiki.services.openoffice.org/wiki/Category:Logging
We have good experiences with this. For instance, our JDBC->SDBC bridge
is paved with logger calls. When logging (for this particular logger) is
not enabled, then this costs nearly no time, since it is just about
noticing that nothing needs to be logged. However, when it is enabled,
then the result is a log file which we can use to examine what went on
on the user's machine (Since the user has to explicitly enable this, and
send us the log file, this isn't a privacy problem).
In particular, the component has a central method for throwing
exceptions, and there, all to-be-thrown exceptions are logged. Together
with method entry guards ("enter foo( bar )", "leaving foo with result
x"), this allows a pretty good analysis.
So, my suggestion would be to create dedicated loggers for your
components, and log the to-be-thrown exceptions.
This is a nice solution. It would help in our case, although the minus
is that it has to be turned on before the problem happens. And some
problems of the mentioned kind, are hardly reproducible.
Thanks,
Mikhail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
