Hi Stephan, > Even if there happen to be exception instances where the exception > message is designed to be meaningfully presented to an end user (do you > indeed use localized exception messages?)
(yes, indeed, we do) > this is not true for the > majority of exception instances (where the exception message is > something that can help a knowing person track down the problem, but not > something that is meaningful for the average end user---for example, it > is always in English). Which I'd consider a bug. If I run an arbitrary macro in Basic which uses the UNO API, any exception which is caught there is reported to the end user. Speaking techno-babble which is not meaningful (I tend to think that Basic developers still are allowed to be, though not necessarily are, average end users) is a usability issue, in my opinion. > For the latter, I see no problem with augmenting > the exception message with file and line information (other than the > ugliness inherent in C/C++ macros). For the former, you should simply > exempt those instances from Mikhail's wholesale macrofication, I would say. I suppose our fundamental question indeed is whether Exception.Message is an end-user feature, or a diagnostic means. If it's the latter, then file/line are well suited there - but it's this premise I doubt. 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]
