No, as when this happens its deep in some serialization stack that has
no ability to know that an improperly written subclass can be safely
replaced with an instance of its baseclass. This is definitely a bug in
antlr and a common mistake since the contract for Serializable was is
often introduced
We should report it to Antlr.
Regarding exceptions it would be good if we started adding some more value
to these exceptions -
it would be so much better if I actually could get the line/column numbers
as getters on the QuerySyntaxException.
The same goes with many of our other exceptions
This is nicer.
By design an exception is Serializable. It's a contract break from
antlr. So the breaking exception list has to be manually maintained.
Steve Ebersole wrote:
A simpler solution would be to just add a writeObject() impl to
HibernateException which culls the cause if it is not se
A simpler solution would be to just add a writeObject() impl to
HibernateException which culls the cause if it is not serializable
(either to null or some "marker").
This would be all encompassing. Plus it would still allow the cause to
be known (so long as no attempt is made to serialize it).
To be more specific,
RecognitionException the cause exception may be not Serializable (eg
antlr.NoViableAltException (AST and Token are not serializable)
Thus JBoss or any remote capable system clashes on remote calls.
Is it OK if we do not propagate the cause exception?
ie
public QuerySyntaxEx
