Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
2.2.0
-
None
Description
As the purpose of the matcher is to find matching attachments, the code is written with the following logic:
1) If there are attachements
1.1) If at least one of them matches, the matcher returns a match.
1.2) If none of them matches
1.2.1) If there is no exception, the matcher returns a no-match.
1.2.2) If there is any exception, the matcher throws a MessagingException.
2) If there are no attachements
2.1) If there is no exception, the matcher returns a no-match.
2.2) If there is any exception, the matcher throws a MessagingException.
The important thing here is that in case 1.1 an exception is never thrown, and it would be a major bug. Instead all the other cases (1.2.1, 1.2.2, 2.1 and 2.2) can all be considered simply as a no-match, and that's why I use (and suggest to use) an onMatchException="noMatch" clause in the invocation if looking for "dangerous" attachments.
In any case, just to avoid any future confusion, we should catch and ignore any exception corresponding to "unsupported" (but irrelevant as not related to attachments) encodings, and let flow up only other types of exceptions, to be handled by an appropriate onMatchException clause whose choice is up to the James administrator.