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 to have a base class for an area of exceptions.
And MailetException is an application mistake like how you would wrap a null pointer exception or indexoutofbounds exception. Or just how something is misconfigured.
If we were using JDK 1.4, I'd say that one could just throw an Exception, maybe with a nested exception inside.
Well, why even throw a wrapped Exception then?
But really... as the tiger, do we really need to differentiate? Maybe just remove (deprecate) MailetException altogether?
Well, is there anything that MailetException can do for us? Is there anything that we might want to tell the container about the exception, or how we want it handled? If MailetException were not a MessagingException the code would have to wrap whatever Exception occurred in a MailetException. At the same time, it could provide some behavioral information to the container, which might help to enhance the on[Matcher|Mailet]Exception handling.
I am not saying that we do. Just throwing it out as food for thought while we explore the topic.
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 reroutable. But, I don't think any kind of existing exception framework can support that.
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".
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
