On Sun, Apr 12, 2009 at 12:41 PM, Markus Wiederkehr <[email protected]> wrote: > On Thu, Apr 9, 2009 at 5:30 PM, Robert Burrell Donkin > <[email protected]> wrote: >> On Thu, Apr 9, 2009 at 11:07 AM, Markus Wiederkehr >> <[email protected]> wrote: >>> On Wed, Apr 8, 2009 at 9:28 AM, Robert Burrell Donkin >>> <[email protected]> wrote: >>>> ATM exceptions contain messages in english. for some upstream use >>>> cases (in particular IMAP), it would be useful to be able to display >>>> to the user an internationalised reasonably diagnostic message. the >>>> actual i18n could be done upstream provided that this library supplied >>>> more information. >>> >>> I am not sure if it is a good idea to confront the user with exception >>> detail messages. I think details messages are often too technical for >>> being of any value to the average user (no insult intended ;-). >>> >>> I usually handle this by only letting the user know that something >>> went wrong. An administrator or technician can then look into the log >>> files and see what's going on. >> >> i agree to some extent. there are lots of cases when that's the only >> solution. >> >> i can also understand why contacting an admin or technician is a >> unnecessary cost in some cases. for example, if a field cannot be >> parsed since it's badly formatted, this is just a data problem with >> the email. i think this could sometimes be reasonably presented to the >> user. > > Then we should probably try to identify the exceptions that can be > presented to the user instead of adding some kind of tag or whatever > to all our exceptions. > > And maybe what we really need is not a translation of the detail > message but an exception that is self-explanatory. What I mean is an > exception that contains all the information about the problem that > occurred in its member fields. Like for example an > IndexOutOfBoundsException that contains not only the detail message > but also the minimal, maximal and actual indexes. Or in case of Mime4j > a FieldParseException that contains the field name.
that would be my preferred solution as well >>> But that's just my two cents.. What would you need to implement what >>> you want? A unique tag for each exception? Easy for our own >>> exceptions, difficult for system library exceptions.. And what about >>> exception chaining? >> >> i'm not so concerned about system library exceptions or chained ones - >> these will usually indicate something that really needs the ops to >> take a look to find out what's gone wrong. something as simple as an >> enumeration or tag should be good enough to allow anyone who wants to >> internationalise. > > But chaining is a problem here. Often you have to wrap an exception A > in an exception B only because the current method's contract does not > permit A to be thrown. Then you would catch B and the information you > are really looking for is hidden inside in A. We have this situation > with MimeException and MimeIOException.. this could be solved given enough exceptions eg FieldParseException and FieldParseIOException - robert
