Hi Stephan, > For one, end-user oriented exception messages simply do not work in > general (think about the category of "unchecked" or "runtime" or > "programmer made a coding mistake" exceptions---what use is it for the > end user to see a localized "Index i=7 was out of bounds of array > xyzStrangeList (ranging from 0 to 3)"?). For another, common practice > *is* to put developer-oriented data into exception messages. > > For randomly picked evidence of the latter take, for example, a quote > from Item 45 of Effective Java: "The string representation of an > exception should not be confused with a user-level error message, which > must be intelligible to end users. Unlike a user-level error message, > it is primarily for the benefit of programmers or field > service-personnel for use when analyzing a failure. Therefore > information content is far more important than intelligibility." (Of > course, there is nothing wrong with questioning common wisdom. I just > personally think that common wisdom is indeed right here.)
And the quote you cited might be an indication I am wrong here :) (though I could try to debate about the difference between an exception's string representation and the exception message :) As a consequence, this would mean that our error handling infrastructure is even worse than I thought: If we cannot use Exception.Message to transport user-messages, or information to *generate* meaningful user messages, then ... With very few exceptions (sic), none our exception classes has additional fields for transporting the necessary information. (Not to mention ... I remember having seen an exception class with an error code field which was not even documented, and used non-UNO SFX-internal error codes. Argh!) So, let's pave our exception messages with techno-babble, for the sake of usability ... who cares :( Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
