Commons Email
  1. Commons Email
  2. EMAIL-42

[email] All exceptions seem to be thrown as messagingExceptions

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Nightly Builds
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Other

      Description

      Pretty much all the exceptions are thrown as newly constructed messagingExceptions.

      Not sure what to do about this, but having an AddressException or other exception thrown by the
      javamail itself would be argueably useful.

      Throwing unsupported char set when setting charset would be better than waiting unit other setters are
      called for example.

      Anyone know if there's a general preference to throw JavaMail exceptions or have commons email
      implement its own?

        Activity

        Hide
        David Eric Pugh added a comment -

        All applied.

        Show
        David Eric Pugh added a comment - All applied.
        Hide
        Mark Lowe added a comment -

        Created an attachment (id=13580)
        [email] tests with try catches not to test for MessagingException

        IMHO having tests that test functionlity should throw exception, and exception
        test in a specialised test case. Not because this is a matter of style, but
        because it doesn't create a maintaince nightmare. Adding a new exception to the
        package shouldn't involve addressing a zillion build errors in the standard
        test cases.

        Show
        Mark Lowe added a comment - Created an attachment (id=13580) [email] tests with try catches not to test for MessagingException IMHO having tests that test functionlity should throw exception, and exception test in a specialised test case. Not because this is a matter of style, but because it doesn't create a maintaince nightmare. Adding a new exception to the package shouldn't involve addressing a zillion build errors in the standard test cases.
        Hide
        Mark Lowe added a comment -

        Created an attachment (id=13579)
        [email] EmailExceptionTest class

        Show
        Mark Lowe added a comment - Created an attachment (id=13579) [email] EmailExceptionTest class
        Hide
        Mark Lowe added a comment -

        Created an attachment (id=13578)
        [email] Email class that throws EmailException.

        Show
        Mark Lowe added a comment - Created an attachment (id=13578) [email] Email class that throws EmailException.
        Hide
        Mark Lowe added a comment -

        Created an attachment (id=13577)
        [email] EmailException src file.

        Show
        Mark Lowe added a comment - Created an attachment (id=13577) [email] EmailException src file.
        Hide
        David Eric Pugh added a comment -

        Interesting.. I like the addressexception idea. However, I don't like that
        adding this starts causing us to throw UnsupportedEncodingException everywhere.
        The idea of commons-email is to hide the details.

        What do you think of introcucing an org.apache.commons.email.EmailException and
        AddressException extending EmailException? EmailException could extend
        NestableException, and then anything we need would be put in there. Regardless
        of wether its an javax.mail.internet.AddressException,
        javax.mail.MessagingException, or UnsupportedEncodingException.

        If you care about what the underlying exception is, then you can dig it out of
        the NestableException. Really, the only exceptions I can see most users
        wanting are 1) a bad addresss, 2) some sort of smtp error. and you could just
        througw EmailException, and then dig the details out if you cared from there..

        ERic

        Show
        David Eric Pugh added a comment - Interesting.. I like the addressexception idea. However, I don't like that adding this starts causing us to throw UnsupportedEncodingException everywhere. The idea of commons-email is to hide the details. What do you think of introcucing an org.apache.commons.email.EmailException and AddressException extending EmailException? EmailException could extend NestableException, and then anything we need would be put in there. Regardless of wether its an javax.mail.internet.AddressException, javax.mail.MessagingException, or UnsupportedEncodingException. If you care about what the underlying exception is, then you can dig it out of the NestableException. Really, the only exceptions I can see most users wanting are 1) a bad addresss, 2) some sort of smtp error. and you could just througw EmailException, and then dig the details out if you cared from there.. ERic
        Hide
        Corey Scott added a comment -

        I think you might find that the Unsupport charset exception is not thrown
        until a bad charset is used in the setter. I am pretty sure that the only
        set/Add address methods throw this exception and it doesnt seem to have much
        to do with the setCharset operations

        Show
        Corey Scott added a comment - I think you might find that the Unsupport charset exception is not thrown until a bad charset is used in the setter. I am pretty sure that the only set/Add address methods throw this exception and it doesnt seem to have much to do with the setCharset operations
        Hide
        Mark Lowe added a comment -

        Created an attachment (id=13347)
        [email] changed to test cases to prove the correct exceptions patch works

        Show
        Mark Lowe added a comment - Created an attachment (id=13347) [email] changed to test cases to prove the correct exceptions patch works
        Hide
        Mark Lowe added a comment -

        Created an attachment (id=13346)
        [emai] addTo, setFrom, addReplyto, addCc and addBcc throws AddressException

        Show
        Mark Lowe added a comment - Created an attachment (id=13346) [emai] addTo, setFrom, addReplyto, addCc and addBcc throws AddressException

          People

          • Assignee:
            Unassigned
            Reporter:
            Mark Lowe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development