Le 09/03/2011 16:55, Jörg Schaible a écrit : > 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.
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. Luc > > - Jörg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
