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]
