commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lowe <>
Subject Re: [email] Exceptions
Date Mon, 29 Nov 2004 10:23:50 GMT
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?


On Mon, 29 Nov 2004 11:11:06 +0100, Eric Pugh <> 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 []
> > 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:
> > For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message