> With respect to exception handling, I don't believe that we need to > complicate the lives of administrators by giving them control over the > outcome of each thrown exception. Exceptions should be > considered in terms > of their semantic meaning. In many cases, there is appropriate behavior, > and no need to expose it to the administrator. In many cases, it may not > even make sense to log it, other than at debug level. Yes, there will be > exceptions that should result in sending a message to the ERROR spool, but > that will probably not be the norm, IMO.
But what you think that should be done to a malformed message that causes an exception to be thrown in a mailet? Send to error spool or continue? And worse, what should be done if thrown in a matcher? Send to error spool, return null or return mail.getRecipients()? Hontvari Jozsef thinks for example that AttachmentFileNameIs used for checking for viruses should send to error spool, I think that it should return null, and I sent you a patch yesterday in that sense. Probably, we are both right. I think that if an exception emerges from a mailet or a matcher, because the code could not decide based on the semantic meaning, the administrators should be given the opportunity to decide for that specific <mailet> entry in config.xml (I don't mean "giving them control over the outcome of *each* thrown exception" but on having *any* exception been thrown). Vincenzo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
