> I'd expect something like:
> throw new TransientMailetException
> (TransientMailetException.DBCONNECTFAILED,"A message",ex);
> It would then be the job of the catcher for TransientMailetException to
> respool or whatever
> Or in the case of a MessagingException
> throw new PermanentMail
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: 21 October 2003 11:14
> To: 'James Developers List'
> Subject: RE: MailetException vs MessagingException
>
>
>
>
>
>
>
> > You would also need to
>
> You would also need to
> add attributes to give more meaningful error messages (either to the
> user or in the log).
> For example:
> -99 (database connection failed, will retry)
> -101 (please wait, resource locked/busy)
Perhaps this is the answer to the original question then, change
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: 21 October 2003 10:43
> To: 'James Developers List'
> Subject: RE: MailetException vs MessagingException
>
>
>
>
>
>
>
> Jason
>
> > In my way of
Jason wrote:
> The trouble is, I think this should be done on a case-by-case basis :(
> I do like the idea though. It would make catching common errors very
> easy, by just binding a default handler to most containers.
Yeah, I think JavaMail intends this to be used case-by-case to notify the
Jason
> In my way of thinking a MailetException ("there was a problem")would be
> (mostly) classed as transient, whereas a MessagingException ("this
> message cannot be processed/delivered due a problem in it") would be
> permanent
> Just my 2p worth...
Ha! I had it exactly the other way rou
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: 21 October 2003 09:47
> To: James Developers List
> Subject: Re: MailetException vs MessagingException
>
>
>
>
>
>
> OTOH I suspect we should consider implementing
OTOH I suspect we should consider implementing listeners to handle
transient and asynchronous failure of transport and store, and keep
exceptions for irrecoverable internal failures.
If we're bound to JavaMail (which we are) specialising messaging exception
to MailetException makes little sens
Serge,
Danny Angus wrote:
>>>Maybe given that we have to catch Exception in the mailet container no
>>>matter what (you can't have runtime exceptions breaking processors), we
>>>should remove MailetException and change the API to "throws Exception".
>>
>> IMO we do want to distingush between
Danny Angus wrote:
Maybe given that we have to catch Exception in the mailet container no
matter what (you can't have runtime exceptions breaking processors), we
should remove MailetException and change the API to "throws Exception".
IMO we do want to distingush between two cases,
Yeah, but how? M
Serge wrote:
> I don't think so. I would like to say MessagingExceptions are
> underlying message problems, i.e., bad parsing or something like that,
> which means they cause the message to get treated more severely.
> Meanwhile other exceptions (MailetException?) are treated as retriable
> or re
Noel J. Bergman wrote:
Far as I can see, MessagingException is used consistently within JavaMail
for all exceptions because of the need to chain. I wonder if
MessagingException would exist were it not for the fact that
java.lang.Exception did not chain until JDK 1.4.
Perhaps, but I think it's good
> > Can you see any reason why the container would want to catch a
> > MailetException and not catch a MessagingException? Can you see any
reason
> > why the container would want to handle them differently? Do we want to
> > Matchers and Mailets to throw MailetException so that we can distinguish
Noel J. Bergman wrote:
I found that many of them are throwing MessagingException-s
instead of MailetException-s (including my own code ;-).
You know ... I could have sworn I had raised this exact question earlier in
the year. I've no clue as to why there are both.
How could we make better use Mail
> > I found that many of them are throwing MessagingException-s
> > instead of MailetException-s (including my own code ;-).
>
> You know ... I could have sworn I had raised this exact question
> earlier in
> the year. I've no clue as to why there are both.
>
> How could we make better use Mail
> I found that many of them are throwing MessagingException-s
> instead of MailetException-s (including my own code ;-).
You know ... I could have sworn I had raised this exact question earlier in
the year. I've no clue as to why there are both.
How could we make better use MailetException, just
P.S.
Scotland 39 - USA 15
:-)
***
The information in this e-mail is confidential and for use by the addressee(s) only.
If you are not the intended recipient (or responsible for delivery of the message to
the intended
Vincenzo,
> I agree, but Matcher.match(Mail), Matcher.init(MatcherConfig),
Mailet.service(Mail) and Mailet.init(MailetConfig) are all defined
> as "throws javax.mail.MessagingException", so I guess that
MailetException must continue to extend MessagingException.
> Now, shall we refactor? It
y the
way systematically add the "@version CVS $Revision:$" javadoc entry). Let me know.
Vincenzo
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: lunedi 20 ottobre 2003 15.02
> To: James Developers List
> Subject: Re: Ma
Vincenzo Gianferrari Pini wrote:
Currently MailetException, whose author was Serge, extends MessagingException without adding anything, so it's indifferent, but there must have been some rationale behind all this in the past, that I'm missing. Some mailets even throw both kinds of exceptions, like
Vincenzo,
> This may be just a matter of clean code, but browsing around the matchers
and mailets in CVS, I found that many of them are
> throwing MessagingException-s instead of MailetException-s (including my
own code ;-).
This is just a guess, but I seem to remember thinking that MailetE
21 matches
Mail list logo
