The usual thing to do with exceptions in a i18n environment is to throw a code for the message, not the actual message. Then you just use the code as a key to look up the localized message in a properties file. This way there's no need to use any custom exceptions.
Stephen Drye Art Technology Group ----- Original Message ----- From: "Cindy Nordahl" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 19, 2001 4:32 AM Subject: RE: I18N: <bundle> Bug? > > The exception may have been thrown by a tag handler or some application > > logic (as opposed to scriplet code). > > If a Tag handler throws an exception, how does it know to throw *my* > implementation of the exception (implements LocalizableException) class? It > seems like I would have to create my own tag and tag handler. > > I understand how I could get scriptlet code to call my implementation of the > exception -- I use the <exception> tag and pass in an instance of my > LocalizableException class as the value attribute and pass in the > ResourceBundle that defines my localized messages. > > Would there ever be any reason to extend an already existing exception class > like javax.servlet.jsp.JspTagException and have it implement > LocalizableException? This way, I could make it display a localized version > of the error message, like "Unparseable date" (for an English locale). Or, > would this be overkill? > > Thank you very much! > > Cindy > > -----Original Message----- > From: Jan Luehe [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 17, 2001 10:28 PM > To: [EMAIL PROTECTED] > Subject: Re: I18N: <bundle> Bug? > > > Hi Cindy: > > > > Thanks again for your detailed response. > > > > I'm having trouble grasping the <exception> tag. This is how I think it > > should work: > > > > Let's say that I create my own exception class that implements > > LocalizableException, called FormValidatorException. > > > > A user fills out a form on a web page. They make some mistakes while > > entering the data -- the password they chose isn't long enough and some > > required fields are left blank. > > > > When the form is submitted, I check to see if the password is invalid: > > > > <% > > FormValidatorException pwExcptn = new FormValidatorException(); > > pageContext.setAttribute("pwExcptn ",pwExcptn); > > FormValidatorException reqExcptn = new FormValidatorException(); > > pageContext.setAttribute("reqExcptn ",reqExcptn ); > > %> > > > > <c:if test = "$passwordInvalid"> > > <c:exception value="$pwExcptn" bundle="$errorBundle"/> > > </c:if> > > > > <c:if test = "$nameFieldEmpty"> > > <c:exception value="$reqExcptn" bundle="$errorBundle"/> > > </c:if> > > > > Am I on the right track? I'm wondering how the right localized string is > > accessed from the errorBundle. How does it know when to display the error > > message for an invalid password? > > > Actually, the main purpose of the <exception> tag is to display > an exception message in its localized form in an error page. > The exception may have been thrown by a tag handler or some application > logic (as opposed to scriplet code). > > By implementing the LocalizableException interface, your exception > provides information about the message key to be looked up in the > resource bundle (see getMessageKey() interface method) and the > parameters (if any) for parametric replacement (see getMessageArgs() > method). This information must be supplied to your exception's constructor. > > Hope this helps. > > > Jan > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
