Skip to main content

Better error traces from XML encoder/decoder

No replies
mgrev
Offline
Joined: 2003-08-12

Today it is very hard to debug when the beans persistance framework is throwing exceptions. A typical stack trace for when you accidentially changed the constructor's arguments for an object being read is:

<br />
=Class.new(Integer, DateFormatList, AtFixed, PaintArray, PaintArray, null, FontArray, IntegerArray, AtFraction, AtFraction);<br />
java.lang.NoSuchMethodException: =Class.new(Integer, DateFormatList, AtFixed, PaintArray, PaintArray, null, FontArray, IntegerArray, AtFraction, AtFraction);<br />
	at java.beans.Statement.invoke(Statement.java:234)<br />
	at java.beans.Expression.getValue(Expression.java:98)<br />
...<br />

If the class name of the object that the framework is trying to instanciate it would be very helpful. If you are reading a file with thousands of objects it's kind of hard to know where to start debugging otherwise.

Also, if you don't have a totally correct .equals() method in the object that you are trying to serialize, say it compares a field that doesn't have a get/set, then the XML encoder loops for a couple of thousand times and then it runs out if stack space... The error message is not very frendly, you don't even get to know which object the encoder is trying to serialize when the stack runs out (because of an infinite loop).

I therefore think it would be appropriate to make the traces from the XML encoder/decoder print somewhat more friendly error messages and have some infinite loop protection that at least prints the class that don't want to serialize itself.

Cheers,
Mikael Grev