commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [math] Re: svn commit: r1078734
Date Wed, 09 Mar 2011 15:55:23 GMT
Hi Gilles,

Gilles Sadowski wrote:

> On Wed, Mar 09, 2011 at 03:00:07PM +0100, Luc Maisonobe wrote:
>> Le 09/03/2011 13:59, Gilles Sadowski a écrit :
>> > Hi.
>> > 
>> >>>> [...]
>> >>>>
>> >>>> Or make the fields transient?
>> >>>>
>> >>>> That would perhaps cause problems if the Exceptions were ever
>> >>>> serialised, but can that happen?
>> >>>
>> >>> Yes, it's a typical JEE scenario and I cannot say how often I cursed
>> >>> Sun for stuffing an unserializable object into
>> >>> NamingException.setResolvedObject within their LDAP implementation
>> >>> ...
>> >>>
>> >>> Actually the MathRE should contain a writeObject implementation that
>> >>> replaces any non-serializable object in that array with some kind of
>> >>> replacement (e.g. with its String representation). Otherwise the
>> >>> MathRE will not reach its destination and all the localization was
>> >>> for nothing.
>> >>
>> >> That's a good idea. We could even do that replacement directly at
>> >> construction and never store the Object themselves, regardless of
>> >> their status with respect to serialization.
>> > 
>> > Do you mean storing only the String representation of the arguments?
>> > Wouldn't that defeat the purpose of the map feature (which was to allow
>> > any kind of objects to be stored and retrieved)?
>> 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.

- Jörg

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

View raw message