commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lowe <mel...@gmail.com>
Subject Re: [email] Exceptions
Date Tue, 30 Nov 2004 09:32:28 GMT
I'll put the exception tests in with the the others, when its all in.
I left most the tests untouched anyhow just testing for EmailException
rather than MessagingException. Once EmailException is in the head
version I'll start thinking about AddressException.

Has the issue of bulk mailing comeup before? I'm thinking of a class
that extends thread and then sends a email report to a specified email
address reporting which have been sent and those that haven't. Does
this fall within the scope of commons email? Email could even extend
thread and then just use the run method when needing to mail to lots
of folk.. This would be handy for webapps where the time it takes to
send mail exceeds the time for the request-reponse cycle.

HtmlEmail email = .. 
.. 
email.batchMail();


public void batchMail() {
      this.run();
}

public void run() {
     try {
         send();
     } catch (SomeExceptionn e) {

     }
}

Or would something else be a better idea? Perhaps a separate class
EmailSender or something?

Mark


On Tue, 30 Nov 2004 11:38:30 +0800, Corey Scott <corey.scott@gmail.com> wrote:
> Sounds good to me, I have a stack of things waiting for the next version.
> Also I think most of the bugs have been cleared off by your recent
> commits so there shouldnt be any reason to stop us from a RC1
> 
> 
> 
> -Corey
> 
> On Mon, 29 Nov 2004 19:01:00 +0100, Eric Pugh <epugh@upstate.com> wrote:
> > I've applied a stack of changes, including Mark's EmailException, to the
> > codebase.   I don't really care much about how the unit tests look, as long
> > as the jcoverage keeps going up!
> >
> > At this point, I think all the API changes are done, and my gut feeling is
> > that we should look to final testing, cut a Release Candidate and then roll
> > 1.0.  We should also start thinking about what the next version will entail.
> >
> >
> >
> > Eric
> >
> > > -----Original Message-----
> > > From: Mark Lowe [mailto:melowe@gmail.com]
> > > Sent: Monday, November 29, 2004 5:25 PM
> > > To: Corey Scott
> > > Cc: Jakarta Commons Developers List; epugh@upstate.com
> > > Subject: Re: [email] Exceptions
> > >
> > >
> > > Okay I'll take a look tommorrow and sumbit my patch with the test
> > > cases in with the Other test methods.
> > >
> > > Judging from you example, you agree that unexpected exceptions should
> > > just get thrown and that exceptions should be tested independently to
> > > normal tests, which all sounds good to me. Or am i wrong? If the
> > > method isn't there to invoke an exception then if one happens then
> > > surely just throw it, the fact that its unexpected will be evident by
> > > virtue of the test failing due to errors.
> > >
> > > Mark
> > >
> > > On Tue, 30 Nov 2004 00:04:16 +0800, Corey Scott
> > > <corey.scott@gmail.com> wrote:
> > > > This is exactly what I was trying to say, just not so elegantly :-)
> > > >
> > > > Eg. Tests for the HtmlEmail class should be in teh HtmlEmailTest class
> > > > or is this becomes too big and you want to separate the exceptions,
> > > > then there should be two classes HtmlEmailTest (for normal test cases)
> > > > and HtmlEmailExceptionTest
> > > >
> > > >
> > > >
> > > > -Corey
> > > >
> > > > On Mon, 29 Nov 2004 16:59:29 +0100, Eric Pugh <epugh@upstate.com>
wrote:
> > > > > Humm...   I typically make all my unit tests throw Exception.
> > >  It reduces
> > > > > the length of each test, especially when all you are doing is
> > > logging that
> > > > > it failed with a fail(ex.getMessage).
> > > > >
> > > > > However, if you are actually TESTING that an exception gets thrown:
> > > > >
> > > > > try {
> > > > > email.doSomething();
> > > > > fail("should have thrown ee");
> > > > > }
> > > > > catch (EmailException ee){
> > > > >        assertTrue(ee.getMessage().indexOf("myerror")>-1)
> > > > > }
> > > > >
> > > > > then I argue they should go in with whatever class we are
> > > testing, because
> > > > > when someone adds a new method to the class, it will
> > > encourage them to add
> > > > > the corresponding test case for any exeption.  Or, put the
> > > exception test
> > > > > into the test.
> > > > >
> > > > > public void testSomething() throws Exception{
> > > > >        email.doSomethign();
> > > > > <snip/>
> > > > > try {
> > > > > email.doSomething();
> > > > > fail("should have thrown ee");
> > > > > }
> > > > > catch (EmailException ee){
> > > > >        assertTrue(ee.getMessage().indexOf("myerror")>-1)
> > > > >
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > > That way everything stays together.  If we aren't actually
> > > asserting the
> > > > > exception, then we shouldn't bother testing it..
> > > > >
> > > > >
> > > > >
> > > > > Eric
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Mark Lowe [mailto:melowe@gmail.com]
> > > > > > Sent: Monday, November 29, 2004 3:19 PM
> > > > > > To: Corey Scott
> > > > > > Cc: Jakarta Commons Developers List
> > > > > > Subject: Re: [email] Exceptions
> > > > > >
> > > > > >
> > > > > > My thoughts on the test cases are that they should throw exception,
> > > > > > and then have the exception testing separate. This would make
the
> > > > > > cases shorter also, perhaps this is what you mean.
> > > > > >
> > > > > > public void testFoo() throws Exception
> > > > > > {
> > > > > >     Foo foo = new Foo();
> > > > > >     foo.setBar("testvar");
> > > > > > }
> > > > > >
> > > > > > For example, if for some reason the exception for setBar() was
ever
> > > > > > changed the case could remain the same as before, and the
> > > only change
> > > > > > would need to be in the exception test case.
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > >
> > > > > > On Mon, 29 Nov 2004 21:59:44 +0800, Corey Scott
> > > > > > <corey.scott@gmail.com> wrote:
> > > > > > > I would prefer an Exception Test case per base class,
> > > especially for
> > > > > > > the larger files.  I know most of the tests I wrote, but
> > > I think that
> > > > > > > if anything the files are too long and would be much more
> > > usable if
> > > > > > > they were shorter and more focused.  Does anyone have any
> > > objections
> > > > > > > to gave more (but shorter) files?
> > > > > > >
> > > > > > > -Corey
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, 29 Nov 2004 14:17:30 +0100, Mark Lowe
> > > <melowe@gmail.com> wrote:
> > > > > > > > I've created the exceptions and I'm now working through
the
> > > > > > test cases.
> > > > > > > >
> > > > > > > > If I summit a patch with the exception testing in
a
> > > ExceptionTestCase
> > > > > > > > what's the likelyhood of this being patched? This
isn't
> > > a question of
> > > > > > > > style its a question of maintainabilty and now, I'm
> > > faced with the
> > > > > > > > task of weeding out all these try catch statements.
> > > > > > > >
> > > > > > > > Any objection to a patch with these exception tests
moved into a
> > > > > > > > specialised test case?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Mark
> > > > > > > >
> > > > > > > > On Mon, 29 Nov 2004 11:23:50 +0100, Mark Lowe
> > > > > > <melowe@gmail.com> wrote:
> > > > > > > > > Okay 2 commons.mail exceptions sounds like an
improvement.
> > > > > > So the goal
> > > > > > > > > is to minimise the catch statements the user
needs to
> > > use, sound
> > > > > > > > > reasonable. Throwing everything would mean 2
catches, so I
> > > > > > can see the
> > > > > > > > > value in catching once.
> > > > > > > > >
> > > > > > > > > I'll look into a way of having a 1.4+ build option
in the
> > > > > > build files
> > > > > > > > > for folk that don't give a gnat's winnit about
1.3 et al.
> > > > > > > > >
> > > > > > > > > Anyone know the default behaviour for the
> > > > > > InternetAddress(email,name)
> > > > > > > > > constructor? Does it adopt the charset from the
parent email?
> > > > > > > > >
> > > > > > > > > Mark
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh
> > > > > > <epugh@upstate.com> wrote:
> > > > > > > > > > My take on this is that users of [email]
are looking for
> > > > > > a package that
> > > > > > > > > > simplifies the JavaMail api.  And one of
the big
> > > > > > simplifing aspects is that
> > > > > > > > > > the Exceptions that they have to catch are
minimized.
> > > > > > Most users will
> > > > > > > > > > probably not care *what* the exception was,
only that
> > > > > > there *was* an
> > > > > > > > > > exception, and just pass it up the chain.
 For folks who
> > > > > > actually have code
> > > > > > > > > > to deal with the specific exception, then
they are either
> > > > > > going to use the
> > > > > > > > > > JavaMail api directly without the extra
layer of [email],
> > > > > > or we should
> > > > > > > > > > provide a way for them to retrieve the specific
Exception.
> > > > > > > > > >
> > > > > > > > > > Hence that is why I propose that we have
two types
> > > of exceptions:
> > > > > > > > > > EmailException and RuntimeEmailException.
 For common
> > > > > > exceptions, we throw
> > > > > > > > > > an EmailException which is an extension
of
> > > > > > NestableException and wraps
> > > > > > > > > > whatever the underlying JavaMail exception
was.  This
> > > > > > provides a nice facade
> > > > > > > > > > for people who don't care what the exception
was, but
> > > > > > allows folks who do to
> > > > > > > > > > get the underlying exception.
> > > > > > > > > >
> > > > > > > > > > The other RuntimeEmailException will extend
> > > > > > NestableRuntimeException and can
> > > > > > > > > > be used for any runtime exceptions in the
same manner as
> > > > > > EmailException.
> > > > > > > > > >
> > > > > > > > > > For the case of the UEE, that would be another
exception
> > > > > > in the API to
> > > > > > > > > > throw, which goes against the charter that:
> > > > > > > > > > "contains a set of Java classes providing
a thin
> > > > > > convenience layer over
> > > > > > > > > > JavaMail".   So, in that case, throw the
approapriate
> > > > > > EmailException and
> > > > > > > > > > that will wrap the UEE.
> > > > > > > > > >
> > > > > > > > > > Mark, is it possible to use the 1.4 io stuff
> > > > > > conditionally?  I guess not,
> > > > > > > > > > but we could think about maybe how we compile
the jar?
> > > > > > Our primary target
> > > > > > > > > > is definitly 1.3 for now though.
> > > > > > > > > >
> > > > > > > > > > Eric
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Mark Lowe [mailto:melowe@gmail.com]
> > > > > > > > > > > Sent: Sunday, November 28, 2004 4:04
PM
> > > > > > > > > > > To: Commons dev list; Corey Scott
> > > > > > > > > > > Subject: [email] Exceptions
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The issue of exceptions has come up
a few times, and
> > > > > > heres a summary
> > > > > > > > > > > of my understanding of whats been said
and agreed and
> > > > > > disagreed about.
> > > > > > > > > > >
> > > > > > > > > > > The idea of throwing AddressException
is favourable,
> > > > > > but not at the
> > > > > > > > > > > cost of needing to throw UnsupportingEncodingException.
> > > > > > When setting
> > > > > > > > > > > InternetAddress() this throws a UEE
and AddressException.
> > > > > > > > > > >
> > > > > > > > > > > My position is that without 1.4's new
io package
> > > > > > there's no means of
> > > > > > > > > > > checking supported charsets on a given
JVM. If the user
> > > > > > enters a shady
> > > > > > > > > > > charset for a email address or name
is there anything
> > > > > > wrong with them
> > > > > > > > > > > having a UEE thrown?
> > > > > > > > > > >
> > > > > > > > > > > The lightest means of doing this in
my opinion is just
> > > > > > throw both, its
> > > > > > > > > > > consistent with the mailapi. It would
work on all
> > > target JVMs.
> > > > > > > > > > >
> > > > > > > > > > > Of course you could just throw MessagingException
for
> > > > > > everything , "oh
> > > > > > > > > > > thats what it does". But is this a
useful and therefore
> > > > > > good thing?
> > > > > > > > > > > Having  a commons.mail.EmailException
was suggested,
> > > > > > but does that
> > > > > > > > > > > have any advantage over throwing AddressException
and
> > > > > > UEE? I'm not
> > > > > > > > > > > sure.
> > > > > > > > > > >
> > > > > > > > > > > I don't mind summitting the patches,
i need to do this
> > > > > > for a project
> > > > > > > > > > > I'm working on at present, so I need
to do the work
> > > > > > anyway. It makes
> > > > > > > > > > > sense to submit this to the effort
but I don't
> > > mind either way.
> > > > > > > > > > >
> > > > > > > > > > > Mark
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail:
> > > > > > commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > > > > > commons-dev-help@jakarta.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> > > commons-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail:
> > > commons-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > >
> > > > >
> > > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > > >
> > > > > ---------------------------------------------------------------------
> > > >
> > > >
> > > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message