Hi. > >>> [...] > >>> You are right, I am stupid. So we have to check for serializable. > >> > >> I don't see why: The serialization will work provided all "Object" > >> arguments are "Serializable"; it is the user's code responsibility to not > >> try serializing the exception when it knows that it contains a > >> non-serializable object. > >> If the exceptions generated from CM contain only serializable objects > >> (which is the case now), then we've done our part. > > > > Yes, but it might not be always directly obvious. It's always annoying, if > > in a client/server scenario an error occurs and suddenly cannot even > > reported to the client. That's why I proposed the customized > > writeObject/readObject for MathRE. The thrown exception should make it > > under > > any circumstances over the wire, even if it means that unserializable > > objects are nulled or replaced with a String representation. Otherwise the > > client simply gets an error and no-one can tell why. However, this is an > > action only for the serialization process. Or ensure - as already proposed > > in this thread - that only serializable types can be added by using an > > appropriate method/type signature. > > Since in this case a complete roundtrip serialization/deserialization > occurs, I think we should convert to null non-serializable objects at > the serialization step as you propose.
I didn't get why they should be set to "null". In revision 1080231, I've replaced non-Serializable objects by a String indicating that the given class cannot be serialized. [I had to remove the "final" modifier on the "messages" and "context" fields because they must be initialized in the "readObject" method...] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
