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
>
>
--
Jacob Hookom - Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets