Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of melowe@gmail.com designates
 64.233.184.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=HX5gGP9U79qeXWuLV3PquWlqHScBE7XFD+8N4OsaxN3/xdCZvlDA8QoK2UVT1LUDLL88/il2+A+odo9GL6W8ViuO4N6/wri2ALu01/lIEXk2lEkG+oL6fFH4/SecKUhZvWD+jRzJNCjOjwZwlSYoDsvCnNjbE9DLsPPPGMbZEuA=
Message-ID: <3e1257da041115011860e2e8c0@mail.gmail.com>
Date: Mon, 15 Nov 2004 10:18:00 +0100
From: Mark Lowe <melowe@gmail.com>
Reply-To: Mark Lowe <melowe@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>,
	epugh@upstate.com
Subject: Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to be
 thrown as messagingExceptions
Cc: Corey Scott <corey.scott@gmail.com>
In-Reply-To: <PKENIMMEAHDAHILNLIJPMECFHFAB.epugh@upstate.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <e8bc90dc04111422174fee3aad@mail.gmail.com>
	 <PKENIMMEAHDAHILNLIJPMECFHFAB.epugh@upstate.com>

I don't mind.. But seems that Javamail already has some exceptions
that we're not using why not use them more adding any new ones?

If we though the UnsupportedEncodingException in the right place, and
then silence is in a reuseable createAddress method.. that should work
shouldn't it?

It seems reasonable to inform the user that the encoding s/he is
trying is dodgy, if done on setCharset() .

Likewise an addressexception when setting addresses. 

I think also controlling the javamail exceptions seems to fit with the
idea of being a bridge between javamail and something simpler.

Mark

On Mon, 15 Nov 2004 09:07:16 -0000, Eric Pugh <epugh@upstate.com> wrote:
> So, we are agreed that we should have an EmailException that should be
> thrown?  And that will wrap any underlying exception?
> 
> EmailException should extend NestableException.
> 
> Eric
> 
> 
> 
> > -----Original Message-----
> > From: Corey Scott [mailto:corey.scott@gmail.com]
> > Sent: Monday, November 15, 2004 6:18 AM
> > To: Jakarta Commons Developers List; Mark Lowe
> > Subject: Re: DO NOT REPLY [Bug 32094] - [email] All exceptions seem to
> > be thrown as messagingExceptions
> >
> >
> > I also like these ideas and am happy to help you implement them if you
> > would like.  However there is one thing we may want to be aware of.  I
> > dont think that the setCharset causes the UnsupportedCharsetException
> > to be throw, I believe that it doesn't check it and therefore allows
> > for any value to be set.  As we are trying to keep email small and
> > maintainable, I dont think it is a good idea to try to added
> > verfication to our classes.  That said, I believe that the only value
> > I came accross during testing that did throw this exception was the
> > setName part of the addresses.  Therefore the unsupported charset
> > exception is thrown for all of the setFrom, addTo, addCc, addBcc, etc
> > functions only at the moment.
> >
> > I hope this helps,
> > Corey
> >
> > ---------------------------------------------------------------------
> > 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