james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: Exception I18n...?
Date Thu, 16 Apr 2009 17:46:27 GMT
On Sun, Apr 12, 2009 at 12:41 PM, Markus Wiederkehr
<markus.wiederkehr@gmail.com> wrote:
> On Thu, Apr 9, 2009 at 5:30 PM, Robert Burrell Donkin
> <robertburrelldonkin@gmail.com> wrote:
>> On Thu, Apr 9, 2009 at 11:07 AM, Markus Wiederkehr
>> <markus.wiederkehr@gmail.com> wrote:
>>> On Wed, Apr 8, 2009 at 9:28 AM, Robert Burrell Donkin
>>> <robertburrelldonkin@gmail.com> 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

Mime
View raw message