Mathias Bauer wrote:
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
May I agree, wholeheartedly?
From my own long years of dealing with users (some of them very angry),
I conclude that the *error* is what bothers them, not the error
*message*. They just want to get their work done. A little techno-babble
is only a small point.
Yes, it is possible to "overwhelm the user with techno-babble"--if we
dump 50 or 60 lines of stack trace on them. Adding file-name and
line-number doesn't qualify as "overwhelming".
And, please do not underrate our users. If we were writing a teaching
program, aimed at grade-school kids, I would agree that we would need to
keep things as simple as possible. But our demographics (from the
surveys) show a huge proportion of adults, 20-60 (and a few old geezers
like me). They can cope.
Consider the opposite case, where user and programmer are _under_whelmed
by lack of information. A real case:
Line 1: "Error saving the document " filename ":"
Line 2: "Error writing file."
I would *kill* for a little techno-babble here (for once, I get to wear
the "angry user" hat). Then I could report the bug, with a chance that
somebody could fix it, even without a reproducible case.
Notice how useful the "wrapper/script" solution is, even for those who
don't want to use its output. The script produces a nice list of patches
(or certainly can be made to), which the programmer can use to check the
adequacy of each exception--and then discard!
Logging errors is an excellent idea. Keeping such logs short enough to
avoid burdening the file system, or performance, but long enough to be
useful, is only a small problem, with several possible solutions. But
logging is a longer-term enhancement, while "wrapping" is available
quickly, and the two are not mutually exclusive. I suggest doing both.
--
T. J. Frazier
Melbourne, FL
(TJFrazier on OO.o)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
