Le 08/03/2011 21:56, sebb a écrit : > On 8 March 2011 20:17, Luc Maisonobe <luc.maison...@free.fr> wrote: >> Le 07/03/2011 11:37, er...@apache.org a écrit : >>> Author: erans >>> Date: Mon Mar 7 10:37:52 2011 >>> New Revision: 1078734 >>> >>> URL: http://svn.apache.org/viewvc?rev=1078734&view=rev >>> Log: >>> MATH-542 >>> "MathRuntimeException" provides two ways for enhancing the information >>> content: >>> one for localized messages and one for storing "context" objects. >>> The additional methods have been added to "MathThrowable". Consequently, >>> dummy >>> implementations were needed in the old "MathRuntimeException" and >>> "MathException". >>> Some parts of the tests for old exceptions were removed as they used methods >>> that were deleted. A call to "MathUserException" in >>> "AbstractContinuousDistribution" >>> was simplified for the same reason. >>> "MathUtils" still contained "String" (instead of "Localizable") as argument >>> to >>> the constructor of a "MathArithmeticException". >>> I don't know why a test in "DummyStepInterpolatorTest" stopped working. It >>> is now >>> commented out; please have a look. >> >> [snip] >> >> >>> Modified: >>> commons/proper/math/trunk/src/test/java/org/apache/commons/math/ode/sampling/DummyStepInterpolatorTest.java >>> URL: >>> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/ode/sampling/DummyStepInterpolatorTest.java?rev=1078734&r1=1078733&r2=1078734&view=diff >>> ============================================================================== >>> --- >>> commons/proper/math/trunk/src/test/java/org/apache/commons/math/ode/sampling/DummyStepInterpolatorTest.java >>> (original) >>> +++ >>> commons/proper/math/trunk/src/test/java/org/apache/commons/math/ode/sampling/DummyStepInterpolatorTest.java >>> Mon Mar 7 10:37:52 2011 >>> @@ -123,7 +123,9 @@ public class DummyStepInterpolatorTest { >>> fail("an exception should have been thrown"); >>> } catch (IOException ioe) { >>> // expected behavior >>> - assertEquals(0, ioe.getMessage().length()); >>> + // XXX Why was the message supposed to be empty? >>> + // With the current code it is "org.apache.commons.math.util.Pair". >>> + // assertEquals(0, ioe.getMessage().length()); >> >> The problem here is that the exception thrown which is an IOException >> built from the empty string in the BadStepInterpolator below is not the >> IOException that is caught here. In fact the IOException caught is >> really a java.io.NotSerializableException which is built with the >> message "org.apache.commons.math.util.Pair" automatically by the >> serialization process in the JVM (at least for Oracle implementation). >> >> All exceptions must be serializable (this comes from java.lang.Throwable >> implementing the Serializable interface). This was also one reason why >> our Localizable interface had to extends Serializable, so it could be >> used as a field in our exceptions. >> >> This change added a List<Pair<Localizable, Object[]>> field in >> MathRuntimeException. Pair is not serializable. Adding Serializable to >> the implemented interfaces in Pair does solve the problem (if also the >> change below is reverted, of course) but I don't think it would be wise >> unless we also enforce the two generic parameters of Pair to be >> serializable too. Perhaps we should use a Map<Localizable, Object[]> >> instead ? >> >> The problem also makes me think that we already had a similar bug in >> another part of the exceptions for a long time : the Object or Object[] >> parameters of the exceptions are stored and may not be Serializable too. >> This was never a problem either because the parameters are often simple >> primitive ones (int, double ...) or arrays so they were serializable. >> Perhaps we should change the signature from Object and Object[] to >> Serializable and Serializable[] ? >> > > Or make the fields transient? > > That would perhaps cause problems if the Exceptions were ever > serialised, but can that happen?
At least, it happen with this test. The purpose of the test is to check the proper handling of a failing deserialization. It seems in the process the JVM does serialize or deserialize the exception too (I don't know why). Another use case I imagine for exception serialization is with distributed applications (SOA and the like). I guess there may be some serialization/deserialization at middleware level. Luc > >>> } >>> >>> } >>> @@ -137,7 +139,7 @@ public class DummyStepInterpolatorTest { >>> } >>> @Override >>> protected void doFinalize() throws MathUserException { >>> - throw new MathUserException((Localizable) null, >>> LocalizedFormats.SIMPLE_MESSAGE, ""); >>> + throw new MathUserException(LocalizedFormats.SIMPLE_MESSAGE, >>> null); >> >> This should not have been replaced. Null is not the smae thing as the >> empty String. Also this introduces a warning due to ambiguous signatures. >> >> Luc >> >>> } >>> } >> >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org