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.
("Access denied" might be a bad example, since this end-user message is
probably generated from some error code, and not an actual exception
message, but I hope you get the idea.)
As a consequence, you *must* strip the file/line info before displaying
the message, and this is what I called error-prone.
(If I had a wish, I'd vote for changing UNO incompatibly, and adding a
"Stack" member to the css.uno.Exception class instead. Oh, well, just
dreaming :)
> 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.
s/extensions/exceptions/, I suppose?
Well ... I hate to say that, but the approach you suggest is clumsy, in
my opinion, for the reasons outlined above.
And the argument "We do not have the time/resources to make it right,
let's do it the quick and dirty way instead" is something which I hear
too often (and suffer from too often, months or years later), for my taste.
But okay, that might be only me. In any case, I *strongly* suggest you
ask user experience what they think about slaying end users (who do not
want to send you the screenshots) with file/line information.
> 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.
One other note: Did you try how this adds to library size, if all those
exceptions are padded with additional strings?
Don't want to say it's not bearable, just wanted to mention that you
should keep an eye on this, too.
> Completely agree, we should. But again, I would not mix those two
> solutions..
See above. In my opinion, the one solution is not a solution, but a hack
only :)
> [logging]
> 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.
Reproducibility is a problem indeed.
Seeing that our latest versions towards 3.1 have this "OpenOffice.org
improvement program" feature, where user actions are anonymously logged,
I wonder whether "log all thrown exceptions" is something which belongs
to "OpenOffice.org improvement", too.
That is, if a user volunteers to let OOo collect data which helps us
making OOo better, why not also logging the thrown exceptions then?
Ciao
Frank
--
- Frank Schönheit, Software Engineer [email protected] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
