You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2009/04/08 09:28:41 UTC

Exception I18n...?

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.

is this worthwhile?

best practice?

opinions?

- robert

Re: Exception I18n...?

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Apr 13, 2009 at 11:03 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> Robert Burrell Donkin 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.
>>
>> is this worthwhile?
>>
>> best practice?
>>
>> opinions?
>>
>> - robert
>
> I personally would very much rather prefer that all diagnostic messages
> could be generated solely based on the class of the exception or its
> properties. I also do not think mime4j should provide any locale specific
> resources to the upstream users.

i would like to see mime4j enable upstream users to programmatically
understand non-system exceptions, and not attempt the localisation
itself. (so, i think we agree on this.)

- robert

Re: Exception I18n...?

Posted by Oleg Kalnichevski <ol...@apache.org>.
Robert Burrell Donkin 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.
> 
> is this worthwhile?
> 
> best practice?
> 
> opinions?
> 
> - robert

I personally would very much rather prefer that all diagnostic messages 
could be generated solely based on the class of the exception or its 
properties. I also do not think mime4j should provide any locale 
specific resources to the upstream users.

Oleg

Re: Exception I18n...?

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Apr 12, 2009 at 12:41 PM, Markus Wiederkehr
<ma...@gmail.com> wrote:
> On Thu, Apr 9, 2009 at 5:30 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> On Thu, Apr 9, 2009 at 11:07 AM, Markus Wiederkehr
>> <ma...@gmail.com> wrote:
>>> On Wed, Apr 8, 2009 at 9:28 AM, Robert Burrell Donkin
>>> <ro...@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

Re: Exception I18n...?

Posted by Markus Wiederkehr <ma...@gmail.com>.
On Thu, Apr 9, 2009 at 5:30 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Thu, Apr 9, 2009 at 11:07 AM, Markus Wiederkehr
> <ma...@gmail.com> wrote:
>> On Wed, Apr 8, 2009 at 9:28 AM, Robert Burrell Donkin
>> <ro...@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

Re: Exception I18n...?

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Apr 9, 2009 at 11:07 AM, Markus Wiederkehr
<ma...@gmail.com> wrote:
> On Wed, Apr 8, 2009 at 9:28 AM, Robert Burrell Donkin
> <ro...@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.

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

- robert

Re: Exception I18n...?

Posted by Markus Wiederkehr <ma...@gmail.com>.
On Wed, Apr 8, 2009 at 9:28 AM, Robert Burrell Donkin
<ro...@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.

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?

Markus