> > 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
> > between one that they threw, and one that was leaked?
> Good question. A tiger will do the same to a human and a monkey, so do
> we really need to create this differentation?
LOL
> Generally I think of MessagingException as a problem with the message
> itself... the repository was corrupted, the headers are unreadable,
> something IO based.
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.
> 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.
> 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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
