commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Re: svn commit: r1078734
Date Thu, 10 Mar 2011 14:18:55 GMT

> >>> [...]
> >>> 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...]


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message