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 13:23:12 GMT
If we're happy that the tests as they stand work then I don't see the
point in fixing anything yet. Might as well refactor tests when new
stuff is added to not to make too larger task of it.

Getting to the point of asking questions about bulk mailing is where I
want to be.

Any good ways of being able to view test emails? It doesn't matter
that much as folk will report such things. Perhaps append to an mbox
of something that can be imported into most clients. I have a dig
around.

Mark

On Tue, 30 Nov 2004 20:44:23 +0800, Corey Scott <corey.scott@gmail.com> wrote:
> For my mine nothing, but I guess that largely depends on you.  The
> only outstanding bugs at the moment are related to the tests and
> exceptions that you raised.  If you want to put these in 1.0 then that
> should just about do it.
> The site looks like it is under control now, good job guys, so I cant
> see anything else outstanding.
> 
> Maybe we should start a RC1 thread?
> 
> 
> 
> -Corey
> 
> On Tue, 30 Nov 2004 13:38:15 +0100, Mark Lowe <melowe@gmail.com> wrote:
> > 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