My guess is that the OptimisticLockException isn't the actually root cause, it's probably a SQLException, which would resolve to the Throwable handler because you don't have anything for the real root cause.
The root cause is a Hibernate exception - but that's what I have already written in my post. And yes, it resolves to the Throwable handler, and that's already written there too.
The point is not to make the
optimisticLockException() handler work.
The point is to make the
unexpectedException() handler work only in case no other handler processed the exception - as a sort of a "generic", "all purpose", "last chance" handler to handle exceptions gracefully and so prevent them from being re-thrown.
Re-thrown exceptions either hit the user in the face or must be handled using some other mechanism, like Faces ExceptionHandler or web.xml error page. Being forced to deal with unexpected exceptions using yet some other technology somehow diminishes appeal of Solder exception mechanism IMHO.
(And as for the root causes: I don't want to write handlers for root causes, SQLExceptions (a painful idea) or Hibernate exceptions - I want to write handlers to portable and meaningful PersistenceExceptions.)
Interesting idea, and you're correct, as it currently stands there really isn't a way to do it. Would you mind adding a JIRA in DeltaSpike (http://issues.apache.org/jira/browse/DELTASPIKE) as this isn't something which will be changed in Seam 3?