This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I am having trouble dealing with exceptions thrown in my managed bean code. Depending on where the exception occurs JSF seems to handle exceptions in it's own sweet way, and it is not consistent between implementations.
Where an exception occurs setting the field on the managed bean:
using the MyFaces implementation results in an error screen which is rather what I had expected. Using the reference implementation however, the exception message is displayed as a message using the <h:message... /> field. I don't think that is very useful
Next I tried throwing the exception from a value change handler. Using MyFaces the exception seems to have been swallowed completely. There seems to be no sign of the exception even in the log. To the user everything looks like it worked OK. The reference implementation did at least log the exception stack trace but then proceeded to invoke the action event handler as if nothing untoward happened. Again the user is left to assume everything is working 100%. Neither behaviour seems appropriate to me.
Is there any way I can gain control of these situations?
That doesn't seem to match my experience. In straight JSF I was seeing non-JSF exceptions get trapped by the JSF servlet and displayed as cryptic stacktrace pages. One of the main reasons I like Facelets is that it can convert those exceptions to something more readable.
In the case of a validator throwing an exception - well that's not something I normally have problems with. Since validators work by throwing (Validation)Exceptions, I throw ValidationExceptions. Anything else, I intercept and convert to a validation exception.
Listeners aren't something I've normally had issues with. I use listeners to listen, not to do heavyweight operations that might throw exceptions. It may simply be that some frameworks are discarding exceptions, since they shouldn't be throwing exceptions anyway.
Exceptions only get logged if something intercepts them and writes them to the log. If something intercepts them and simply eats them, all bets are off. And in a webapp, pretty much every exception gets consumed at some level - otherwise the exception would take down the webapp, or even the webapp container.
Customer surveys are for companies who didn't pay proper attention to begin with.