commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [email] Exceptions
Date Tue, 30 Nov 2004 13:02:30 GMT
ByteArrayDataSource needs a test or two..  Aside from that, maybe check over
the docs and the javadocs.  I am thinking we do an RC on thursday, give it a
week, and roll next week?
Eric

> -----Original Message-----
> From: Mark Lowe [mailto:melowe@gmail.com]
> Sent: Tuesday, November 30, 2004 1:38 PM
> To: Corey Scott
> Cc: Jakarta Commons Developers List; epugh@upstate.com
> Subject: Re: [email] Exceptions
>
>
> What needs to be done for 1.0 then? Give me a list and i'll put some
> time aside to pitch in.
>
>
>
> On Tue, 30 Nov 2004 20:35:48 +0800, Corey Scott
> <corey.scott@gmail.com> wrote:
> > Definately something we should add to our discussion list once 1.0 is
> > out of the way.
> >
> > -Corey
> >
> >
> >
> >
> > On Tue, 30 Nov 2004 10:32:28 +0100, Mark Lowe <melowe@gmail.com> wrote:
> > > 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