> All this would consist in organizing the configuration and having
> it understood by the administrators, but also reviewing the
> try/catch code in the mailets and matchers, going in the opposite
> way of my patch. Perhaps also have the exception stored with a
> setErrorMessage(String) and not only logged, so that it is
> forwarded by NotifyPostmaster together with the message.
Thinking more about it, the key point is perhaps that while the (IMHO) very nice java
exception mechanism, with the "throws" declaration enforced at compile time, allows
for a good coding practice of having each level in the call stack manage its pertinent
exceptions appropriately and deciding whether to continue or not, in the
matcher/mailet stack there is a level that never gets involved, and therefore can not
manage its pertinent exceptions: "the config.xml logic"!
Maybe the right approach is to have two general init parameters (defaulting to
"error"):
<onMatchError>match/noMatch/error/"a processor"</onMatchError>
for the matchers and
<onError>continue/error/"a processor"</onError>
for the mailets.
Those parameters, together with the distinction between a different error processors
that Noel introduced, could IMHO nicely solve everything.
Unless I miss something, is should be easy to do this inserting in
LinearProcessor.service(MailImpl) the code that handles it; a concious mailet
(unfortunately not a matcher) could override the main behaviour just accessing the
<onError> parameter at catch time.
Thoughts?
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
