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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
