Well, the InvocationTargetException shouldn't have existed in the
example stack traces since the EL spec says it should be unwrapped and
thrown as an EL exception. If anything, it should just let it pass through.
Adam Winer wrote:
> Yee-ouch. That's an issue with Ryan's patch too, I think.
>
> -- Adam
>
>
>
> Jacob Hookom wrote:
>
>> I don't necessarily like that idea-- in Facelets, now you've just
>> lost the ELException that knew where the error originated from in
>> your page too.
>>
>> Adam Winer wrote:
>>
>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
--
Jacob Hookom - Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets