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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > > > > 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: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
