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 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".
IMO we do want to distingush between two cases, case 1: unexpected exception thrown by something invoked by the mailet and not caught. Serge's IO style exception case 2: exception thrown (or rethrown) explicity by the mailet to indicate that it cannot complete it's task. Serge's servlet style exception. The container might choose to re-spool the message a number of times in case one, but abandon the attempt to ERROR immediately in the second case. I favour a specific Mailet exception in the second case, and the mailet spec should make it clear that throwing this exception indicates that this mail is unprocessable by this mailet/matcher. In the first case MessagingException will propogate down to the container if we change the method sig of the methods Vincenzo identified. What I think is probably bad is for both cases to be an instance of (and castable to) the same exception, particularly if we think that developers should be handling them in different ways. I'm not greatly bothered though, just expressing an interest. :-) d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
