Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: pass (athena.apache.org: domain of markus.wiederkehr@gmail.com
 designates 209.85.218.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=gngLAm0oKjoh4R4+pc0tqhL6MgWI+4rTe8yMDcOI9Wk1FknosKPpUihlIJodOabotQ
         Swq87eNmQW6ZamdL9md+Rqb5LmaT9rJPyV5sXzPXVHuf8yqA1xPp2g2Jq0N4OdqWNIs/
         eH3IgyvBGC7iw4NcRt/BuGaciDkntBfvOh56Q=
MIME-Version: 1.0
In-Reply-To: <f470f68e0904090830i3f347694m2092ff43e160e1e4@mail.gmail.com>
References: <f470f68e0904080028t11e0faa6ife82f922ade3e3f2@mail.gmail.com>
	 <a92573960904090307g692f048u740b07bc3f2b9833@mail.gmail.com>
	 <f470f68e0904090830i3f347694m2092ff43e160e1e4@mail.gmail.com>
Date: Sun, 12 Apr 2009 13:41:58 +0200
Message-ID: <a92573960904120441w1f866fdcua463a6d0869bc15f@mail.gmail.com>
Subject: Re: Exception I18n...?
From: Markus Wiederkehr <markus.wiederkehr@gmail.com>
To: mime4j-dev@james.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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.

>> 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..

Markus