Noel,
I know, and my opinion is/was (I'm not so sure though) to have onException control
only MessagingException-s, also because Mailet.service(Mail) can throw only
MessagingException-s, and so only Error-s and RuntimeException-s (programming errors
and system malfunctions) can percolate up to LinearProcessor.
So, the way things are coded now, a Mailet or Matcher programmer is forced by the java
compiler to catch all normal (event related) Exception-s, and has to "throw new
MessagingException(String, Throwable)" if he wants to send it up and leave the choice
to the config administrator. And also this way a programming error (RuntimeException)
will not be hidden and will go to the error processor, so that someone would be
invoked to fix it.
I'm really not sure about it. If we control now only MessagingException-s we can later
on change our mind and control also Exception-s (or even Throwable-s), but the reverse
is not true. But on other part "onException" does not mean "onMessagingException".
Let me know your opinion, as now I'm 50-50, so I leave it up to you. Tomorrow morning
after your answer I can quickly change the things and send another patch.
But we have to fix the endless loop problem asap.
Vincenzo
>Vincenzo,
>
> //We got an error... send it to the requested processor
>+ if (!(e instanceof MessagingException)) {
>+ //We got an error... send it to the error processor
>+ mail.setState(Mail.ERROR);
>+ }
> mail.setErrorMessage(e.getMessage());
>
>Are you sure about this change? It is correct in terms of the previous one,
>but it points out a lack in the prior patch: not all Exceptions will be
>MessagingExceptions. Do we only want onException to catch
>MessagingException instances, or do we want it to catch others?
>
> --- Noel
>
>-----Original Message-----
>From: Vincenzo Gianferrari Pini
>[mailto:[EMAIL PROTECTED]
>Sent: Tuesday, June 17, 2003 8:08
>To: List James-Dev
>Subject: [PATCH]Endless loop in JamesSpoolManager
>
>
>The new "on{Match|Mailet}Exception" support introduced in 2.2.0a5 was
>causing an endless "config.xml" loop caused by JamesSpoolManager not setting
>state to Mail.ERROR in case of an Exception not instance of
>MessagingException being thrown by a Mailet or Matcher. In such situation
>the message was resent to the current processor instead of going to
>Mail.ERROR.
>
>Vincenzo
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
