For debugging, I'd rather have this block start with:
} catch (ELException ee) {
if (ee.getCause() instanceof RuntimeException {
throw ((RuntimeException) ee.getCause());
}
... etc ...
}
... because to my mind, if my action handler throws
a NullPointerException, I *want* to see the NullPointerException
coming right from my code.
-- Adam
Ryan Lubke wrote:
> Adam Winer wrote:
>> Shouldn't RuntimeExceptions thrown by a MethodExpression
>> simply be re-thrown?
> My guess is the fact that an ELException is caught is a relic from before
> ELException was made a RuntimeException.
>
> As an alternative to the previous change bundle or just rethrowing
> it, what do you think of doing something like this:
> ======================================================
> } catch (ELException ee) {
> ResourceBundle bundle = LOGGER.getResourceBundle();
> String summaryMessage =
>
> bundle.getString("user.informational.error_processing_page");
> String detailMessage = MessageFormat.format(
> bundle.getString(
> "severe.event.exception_invoking_processaction"),
> ee.getCause().getClass().getName(),
> methodExpression.getExpressionString(),
> actionEvent.getComponent().getId()
> );
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.log(Level.SEVERE, detailMessage, ee.getCause());
> }
> FacesMessage fMessage = new
> FacesMessage(FacesMessage.SEVERITY_ERROR,
> summaryMessage,
> detailMessage);
>
> context.addMessage(actionEvent.getComponent().getClientId(context),
> fMessage); throw new
> AbortProcessingException(ee.getMessage(), ee.getCause());
> }
> ======================================================
>
> Might be nicer than having an exception appear in the browser, but
> perhaps we shouldn't try to do some much from the API itself?
>
>
>>
>> -- Adam
>>
>>
>> Ed Burns wrote:
>>>>>>>> On Wed, 22 Feb 2006 09:32:47 -0800, Ryan Lubke
>>>>>>>> <Ryan.Lubke_at_Sun.COM> said:
>>>
>>> RL> This change bundle addresses one issue[1] pointed out by Cay
>>> Horstmann, and
>>> RL> opens a whole new can of worms (that can being the localization
>>> of the API).
>>>
>>> RL> [1] http://www.horstmann.com/elvis/hated-error-messages.html
>>>
>>> RL> SECTION: Modified Files
>>> RL> ----------------------------
>>> RL> M build.xml
>>> RL> - include the LogStrings.properties in jsf-api.jar
>>>
>>> RL> M src/javax/faces/event/MethodExpressionActionListener.java
>>> RL> - log an informational error message when the MethodExpression
>>> RL> throws an Exception. The AbortProcessing exception is caught
>>> RL> by UIViewRoot, but it ignores it to allow the processing of other
>>> RL> events.
>>>
>>>
>>> RL> A src/javax/faces/LogStrings.properties
>>> RL> - thus begins the long journey of localizing the API
>>>
>>> Very nice.
>>>
>>> r=edburns
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>