[math] Exception Design

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[math] Exception Design

ole ersoy
Hi,

I was considering jumping into the JDKRandomGenerator exception discussion, but I did not want to hijack it.

Not sure if any of you have had a chance to looks at this:
https://github.com/firefly-math/firefly-math-exceptions/
https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java

I think it satisfies everyone's requirements with:
- A single MathException (No hierarchy)
- The ExceptionTypes Enum contains all the exception types
- The ExceptionTypes Enum 'key' maps to the corresponding message 1 to 1
- The ExceptionFactory (Utility) throws exceptions, if necessary, that have always have a single unique root cause, such as NPEs
- The context captures the exception parameters keyed by an the 'ExceptionKeys' enum.  Each module can introduce more keys as necessary.
- The toString() method can be used as the initial exception message

The way developers should deal with this exception is:
1) Catch
2) Get the type (Enum)
3) Get the  parameters (Context)
4) Get the method that threw it
5) Get the class threw it
6) Rethrow the above in an application specific exception, log it, or display it.  Construct a localized message using the enum type to look up the exception template if needed.

WDYT?

Cheers,
- Ole

P.S. Here's the entire test demo (Pasted below for convenience):
https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/test/java/com/fireflysemantics/math/exceptions/MathExceptionTest.java

/**
   *  Licensed under the Apache License, Version 2.0 (the "License");
   *  you may not use this file except in compliance with the License.
   *  You may obtain a copy of the License at
   *
   *  http://www.apache.org/licenses/LICENSE-2.0
   *
   *  Unless required by applicable law or agreed to in writing, software
   *  distributed under the License is distributed on an "AS IS" BASIS,
   *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   *  See the License for the specific language governing permissions and
   *  limitations under the License.
   */

package com.fireflysemantics.math.exceptions;

import static com.fireflysemantics.math.exception.ExceptionKeys.CONSTRAINT;
import static com.fireflysemantics.math.exception.ExceptionKeys.VALUE;
import static com.fireflysemantics.math.exception.ExceptionTypes.NUMBER_TOO_SMALL;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.Test;

import com.fireflysemantics.math.exception.ExceptionFactory;
import com.fireflysemantics.math.exception.MathException;

public class MathExceptionTest {

     @Test(expected = MathException.class)
     public void verifyThrows() {
         throw new MathException(NUMBER_TOO_SMALL);
     }

     @Test
     public void verifyCode() {
         try {
             throw new MathException(NUMBER_TOO_SMALL);
         } catch (MathException e) {
             assertEquals(e.getType(), NUMBER_TOO_SMALL);
         }
     }

     @Test
     public void verifyContext() {
         try {
             throw new MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, 2).put(VALUE, 1);
         } catch (MathException e) {
             assertEquals(e.get(CONSTRAINT), 2);
             assertEquals(e.get(VALUE), 1);
         }
     }

     @Test
     public void verifyToString() {
         try {
             throw new MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, 2).put(VALUE, 1);
         } catch (MathException e) {
assertTrue(e.toString().contains(NUMBER_TOO_SMALL.toString()));
             assertTrue(e.toString().contains("1"));
             assertTrue(e.toString().contains("2"));
             assertTrue(e.toString().contains(CONSTRAINT));
             assertTrue(e.toString().contains(VALUE));
         }
     }

     @Test
     public void verifyFactory() {
         try {
             ExceptionFactory.throwNumberToSmallException(1, 2, "foo");
         } catch (MathException e) {
             assertTrue(e.getType() == NUMBER_TOO_SMALL);
             assertEquals(e.get(CONSTRAINT), new Integer(2));
             assertEquals(e.get(VALUE), new Integer(1));
             assertEquals(e.get("foo"), new Integer(1));
         }
     }
}


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Gilles Sadowski
On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
> Hi,
>
> I was considering jumping into the JDKRandomGenerator exception
> discussion, but I did not want to hijack it.
>
> Not sure if any of you have had a chance to looks at this:
> https://github.com/firefly-math/firefly-math-exceptions/
>
> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java

I had a rapid look; unfortunately not in sufficient details to
grasp the major departures from the existing framework.
Could you display one or two examples comparing CM and firefly?

It looks neat.
But I did not see how localization is handled.

> I think it satisfies everyone's requirements with:
> - A single MathException (No hierarchy)

That would not satisfy everyone. :-!

> - The ExceptionTypes Enum contains all the exception types
> - The ExceptionTypes Enum 'key' maps to the corresponding message 1
> to 1
> - The ExceptionFactory (Utility) throws exceptions, if necessary,
> that have always have a single unique root cause, such as NPEs

I was wondering whether the "factory" idea could indeed satisfy
everyone.

Rather than throwing the non-standard "MathException", the factory
would
generate one of the standard exceptions, constructed with the internal
"MathException" as its cause:

public class ExceptionFactory {

   public static void throwIllegalArgumentException(MathException e) {
     throw new IllegalArgumentException(e);
   }

   public static void throwNullPointerException(MathException e) {
     throw new NullPointerException(e);
   }

   // And so on...
}

So, CM code would be

public class Algo {

   public void evaluate(double value) {
     // Check precondition.
     final double min = computeMin();
     if (value < min) {
       final MathException e = new
MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE, value);
       ExceptionFactory.throwIllegalArgumentException(e);
     }

     // Precondition OK.
   }
}


Then, in an application's code:

public void appMethod() {
   // ...

   // Use CM.
   try {
     Algo a = new Algo();
     a.evaluate(2);
   } catch (IllegalArgumentException iae) {
     final Throwable cause = iae.getCause();
     if (cause instanceof MathException) {
       final MathException e = (MathException) cause;

       // Rethrow an application-specific exception that will make more
sense
       // to my customers.
       throw new InvalidDataInputException(e.get(CONSTRAINT),
e.get(VALUE));
     }
   }
}

This is all untested.
Did I miss something?

Gilles


> - The context captures the exception parameters keyed by an the
> 'ExceptionKeys' enum.  Each module can introduce more keys as
> necessary.
> - The toString() method can be used as the initial exception message
>
> The way developers should deal with this exception is:
> 1) Catch
> 2) Get the type (Enum)
> 3) Get the  parameters (Context)
> 4) Get the method that threw it
> 5) Get the class threw it
> 6) Rethrow the above in an application specific exception, log it, or
> display it.  Construct a localized message using the enum type to
> look
> up the exception template if needed.
>
> WDYT?
>
> Cheers,
> - Ole
>
> P.S. Here's the entire test demo (Pasted below for convenience):
>
> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/test/java/com/fireflysemantics/math/exceptions/MathExceptionTest.java
>
> /**
>   *  Licensed under the Apache License, Version 2.0 (the "License");
>   *  you may not use this file except in compliance with the License.
>   *  You may obtain a copy of the License at
>   *
>   *  http://www.apache.org/licenses/LICENSE-2.0
>   *
>   *  Unless required by applicable law or agreed to in writing,
> software
>   *  distributed under the License is distributed on an "AS IS"
> BASIS,
>   *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
>   *  See the License for the specific language governing permissions
> and
>   *  limitations under the License.
>   */
>
> package com.fireflysemantics.math.exceptions;
>
> import static
> com.fireflysemantics.math.exception.ExceptionKeys.CONSTRAINT;
> import static
> com.fireflysemantics.math.exception.ExceptionKeys.VALUE;
> import static
> com.fireflysemantics.math.exception.ExceptionTypes.NUMBER_TOO_SMALL;
> import static org.junit.Assert.assertEquals;
> import static org.junit.Assert.assertTrue;
>
> import org.junit.Test;
>
> import com.fireflysemantics.math.exception.ExceptionFactory;
> import com.fireflysemantics.math.exception.MathException;
>
> public class MathExceptionTest {
>
>     @Test(expected = MathException.class)
>     public void verifyThrows() {
>         throw new MathException(NUMBER_TOO_SMALL);
>     }
>
>     @Test
>     public void verifyCode() {
>         try {
>             throw new MathException(NUMBER_TOO_SMALL);
>         } catch (MathException e) {
>             assertEquals(e.getType(), NUMBER_TOO_SMALL);
>         }
>     }
>
>     @Test
>     public void verifyContext() {
>         try {
>             throw new MathException(NUMBER_TOO_SMALL).put(CONSTRAINT,
> 2).put(VALUE, 1);
>         } catch (MathException e) {
>             assertEquals(e.get(CONSTRAINT), 2);
>             assertEquals(e.get(VALUE), 1);
>         }
>     }
>
>     @Test
>     public void verifyToString() {
>         try {
>             throw new MathException(NUMBER_TOO_SMALL).put(CONSTRAINT,
> 2).put(VALUE, 1);
>         } catch (MathException e) {
> assertTrue(e.toString().contains(NUMBER_TOO_SMALL.toString()));
>             assertTrue(e.toString().contains("1"));
>             assertTrue(e.toString().contains("2"));
>             assertTrue(e.toString().contains(CONSTRAINT));
>             assertTrue(e.toString().contains(VALUE));
>         }
>     }
>
>     @Test
>     public void verifyFactory() {
>         try {
>             ExceptionFactory.throwNumberToSmallException(1, 2,
> "foo");
>         } catch (MathException e) {
>             assertTrue(e.getType() == NUMBER_TOO_SMALL);
>             assertEquals(e.get(CONSTRAINT), new Integer(2));
>             assertEquals(e.get(VALUE), new Integer(1));
>             assertEquals(e.get("foo"), new Integer(1));
>         }
>     }
> }


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

ole ersoy


On 12/21/2015 06:44 PM, Gilles wrote:

> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>> Hi,
>>
>> I was considering jumping into the JDKRandomGenerator exception
>> discussion, but I did not want to hijack it.
>>
>> Not sure if any of you have had a chance to looks at this:
>> https://github.com/firefly-math/firefly-math-exceptions/
>>
>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>
> I had a rapid look; unfortunately not in sufficient details to
> grasp the major departures from the existing framework.
> Could you display one or two examples comparing CM and firefly?
In addition to what I summarized below one detail that I think is important is that the ExceptionTypes enum allows for more exact targeting of the exception root cause.  For instance right now I have the following arithmetic exception types:

     /**
      * MATH ARITHMETIC EXCEPTIONS
      */
     MAE("MAE"),
     MAE__INTEGER_OVERFLOW("MAE__INTEGER_OVERFLOW"),
     MAE__LONG_OVERFLOW("MAE__LONG_OVERFLOW"),
     MAE__OVERFLOW_IN_ADDITION("MAE__OVERFLOW_IN_ADDITION"),
     MAE__OVERFLOW_IN_SUBTRACTION("MAE__OVERFLOW_IN_SUBTRACTION"),
     MAE__GCD_OVERFLOW_32_BITS("MAE__GCD_OVERFLOW_32_BITS"),
     MAE__GCD_OVERFLOW_64_BITS("MAE__GCD_OVERFLOW_64_BITS"),
     MAE__LCM_OVERFLOW_32_BITS("MAE__LCM_OVERFLOW_32_BITS"),
     MAE__LCM_OVERFLOW_64_BITS("MAE__LCM_OVERFLOW_64_BITS"),
     MAE__DIVISION_BY_ZERO("MAE__DIVISION_BY_ZERO"),

So by looking at the exception type we know exactly what the issue is.  With this approach CM will always only have 1 exception.  If more types are needed then just add another line to the ExceptionTypes Enum.  The new type is used to look up the message template in the I18N resource bundle.


>
> It looks neat.
Thanks :)
> But I did not see how localization is handled.

I did leave localization out.  I think localization was a hard requirement in earlier versions of CM, but I'm hoping that there is some flexibility on this and that future versions can defer to a utility that uses the ExceptionTypes Enum instance as the key to look up the internationalized template string.

>
>> I think it satisfies everyone's requirements with:
>> - A single MathException (No hierarchy)
>
> That would not satisfy everyone. :-!
>
>> - The ExceptionTypes Enum contains all the exception types
>> - The ExceptionTypes Enum 'key' maps to the corresponding message 1 to 1
>> - The ExceptionFactory (Utility) throws exceptions, if necessary,
>> that have always have a single unique root cause, such as NPEs
>
> I was wondering whether the "factory" idea could indeed satisfy
> everyone.
>
> Rather than throwing the non-standard "MathException", the factory would
> generate one of the standard exceptions, constructed with the internal
> "MathException" as its cause:
I think it's good that CM throws CM specific exceptions.  This way when I write the handler I can know that the exception is CM specific without having to unwrap it.

>
> public class ExceptionFactory {
>
>   public static void throwIllegalArgumentException(MathException e) {
>     throw new IllegalArgumentException(e);
>   }
>
>   public static void throwNullPointerException(MathException e) {
>     throw new NullPointerException(e);
>   }
>
>   // And so on...
> }
>
> So, CM code would be
>
> public class Algo {
>
>   public void evaluate(double value) {
>     // Check precondition.
>     final double min = computeMin();
>     if (value < min) {
>       final MathException e = new MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE, value);
>       ExceptionFactory.throwIllegalArgumentException(e);
>     }
>
>     // Precondition OK.
>   }
> }
Another thing that I hinted to is that the the factory builds in the precondition check in the throw method.  So that the line:

     if (value < min) {

can be nixed.

>
>
>
> Then, in an application's code:
>
> public void appMethod() {
>   // ...
>
>   // Use CM.
>   try {
>     Algo a = new Algo();
>     a.evaluate(2);
>   } catch (IllegalArgumentException iae) {
>     final Throwable cause = iae.getCause();
>     if (cause instanceof MathException) {
>       final MathException e = (MathException) cause;
>
>       // Rethrow an application-specific exception that will make more sense
>       // to my customers.
>       throw new InvalidDataInputException(e.get(CONSTRAINT), e.get(VALUE));
>     }
>   }
> }
>
> This is all untested.
> Did I miss something?

I think you got it all...But the handler will be shorter if the exception is not wrapped.  The pattern I'm used to is that libraries wrap the exceptions of other libraries in order to offer a standardized facade to the user.  For example Spring wraps Hibernate exceptions, since Spring is a layer on top of Hibernate and other data access providers.

Ole

>
> Gilles
>
>
>> - The context captures the exception parameters keyed by an the
>> 'ExceptionKeys' enum.  Each module can introduce more keys as
>> necessary.
>> - The toString() method can be used as the initial exception message
>>
>> The way developers should deal with this exception is:
>> 1) Catch
>> 2) Get the type (Enum)
>> 3) Get the  parameters (Context)
>> 4) Get the method that threw it
>> 5) Get the class threw it
>> 6) Rethrow the above in an application specific exception, log it, or
>> display it.  Construct a localized message using the enum type to look
>> up the exception template if needed.
>>
>> WDYT?
>>
>> Cheers,
>> - Ole
>>
>> P.S. Here's the entire test demo (Pasted below for convenience):
>>
>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/test/java/com/fireflysemantics/math/exceptions/MathExceptionTest.java
>>
>> /**
>>   *  Licensed under the Apache License, Version 2.0 (the "License");
>>   *  you may not use this file except in compliance with the License.
>>   *  You may obtain a copy of the License at
>>   *
>>   *  http://www.apache.org/licenses/LICENSE-2.0
>>   *
>>   *  Unless required by applicable law or agreed to in writing, software
>>   *  distributed under the License is distributed on an "AS IS" BASIS,
>>   *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>>   *  See the License for the specific language governing permissions and
>>   *  limitations under the License.
>>   */
>>
>> package com.fireflysemantics.math.exceptions;
>>
>> import static com.fireflysemantics.math.exception.ExceptionKeys.CONSTRAINT;
>> import static com.fireflysemantics.math.exception.ExceptionKeys.VALUE;
>> import static
>> com.fireflysemantics.math.exception.ExceptionTypes.NUMBER_TOO_SMALL;
>> import static org.junit.Assert.assertEquals;
>> import static org.junit.Assert.assertTrue;
>>
>> import org.junit.Test;
>>
>> import com.fireflysemantics.math.exception.ExceptionFactory;
>> import com.fireflysemantics.math.exception.MathException;
>>
>> public class MathExceptionTest {
>>
>>     @Test(expected = MathException.class)
>>     public void verifyThrows() {
>>         throw new MathException(NUMBER_TOO_SMALL);
>>     }
>>
>>     @Test
>>     public void verifyCode() {
>>         try {
>>             throw new MathException(NUMBER_TOO_SMALL);
>>         } catch (MathException e) {
>>             assertEquals(e.getType(), NUMBER_TOO_SMALL);
>>         }
>>     }
>>
>>     @Test
>>     public void verifyContext() {
>>         try {
>>             throw new MathException(NUMBER_TOO_SMALL).put(CONSTRAINT,
>> 2).put(VALUE, 1);
>>         } catch (MathException e) {
>>             assertEquals(e.get(CONSTRAINT), 2);
>>             assertEquals(e.get(VALUE), 1);
>>         }
>>     }
>>
>>     @Test
>>     public void verifyToString() {
>>         try {
>>             throw new MathException(NUMBER_TOO_SMALL).put(CONSTRAINT,
>> 2).put(VALUE, 1);
>>         } catch (MathException e) {
>> assertTrue(e.toString().contains(NUMBER_TOO_SMALL.toString()));
>>             assertTrue(e.toString().contains("1"));
>>             assertTrue(e.toString().contains("2"));
>>             assertTrue(e.toString().contains(CONSTRAINT));
>>             assertTrue(e.toString().contains(VALUE));
>>         }
>>     }
>>
>>     @Test
>>     public void verifyFactory() {
>>         try {
>>             ExceptionFactory.throwNumberToSmallException(1, 2, "foo");
>>         } catch (MathException e) {
>>             assertTrue(e.getType() == NUMBER_TOO_SMALL);
>>             assertEquals(e.get(CONSTRAINT), new Integer(2));
>>             assertEquals(e.get(VALUE), new Integer(1));
>>             assertEquals(e.get("foo"), new Integer(1));
>>         }
>>     }
>> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Gilles Sadowski
Hi.

On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:

> On 12/21/2015 06:44 PM, Gilles wrote:
>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>> Hi,
>>>
>>> I was considering jumping into the JDKRandomGenerator exception
>>> discussion, but I did not want to hijack it.
>>>
>>> Not sure if any of you have had a chance to looks at this:
>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>
>>>
>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>
>> I had a rapid look; unfortunately not in sufficient details to
>> grasp the major departures from the existing framework.
>> Could you display one or two examples comparing CM and firefly?
> In addition to what I summarized below one detail that I think is
> important is that the ExceptionTypes enum allows for more exact
> targeting of the exception root cause.  For instance right now I have
> the following arithmetic exception types:
>
>     /**
>      * MATH ARITHMETIC EXCEPTIONS
>      */
>     MAE("MAE"),
>     MAE__INTEGER_OVERFLOW("MAE__INTEGER_OVERFLOW"),
>     MAE__LONG_OVERFLOW("MAE__LONG_OVERFLOW"),
>     MAE__OVERFLOW_IN_ADDITION("MAE__OVERFLOW_IN_ADDITION"),
>     MAE__OVERFLOW_IN_SUBTRACTION("MAE__OVERFLOW_IN_SUBTRACTION"),
>     MAE__GCD_OVERFLOW_32_BITS("MAE__GCD_OVERFLOW_32_BITS"),
>     MAE__GCD_OVERFLOW_64_BITS("MAE__GCD_OVERFLOW_64_BITS"),
>     MAE__LCM_OVERFLOW_32_BITS("MAE__LCM_OVERFLOW_32_BITS"),
>     MAE__LCM_OVERFLOW_64_BITS("MAE__LCM_OVERFLOW_64_BITS"),
>     MAE__DIVISION_BY_ZERO("MAE__DIVISION_BY_ZERO"),

Side remark: The argument to the enum element is the same as the enum
element's name; is there a way to avoid the duplication (i.e. the
string
would be generated automatically)?

> So by looking at the exception type we know exactly what the issue
> is.
> With this approach CM will always only have 1 exception.  If more
> types are needed then just add another line to the ExceptionTypes
> Enum.  The new type is used to look up the message template in the
> I18N resource bundle.
>
>
>>
>> It looks neat.
> Thanks :)
>> But I did not see how localization is handled.
>
> I did leave localization out.  I think localization was a hard
> requirement in earlier versions of CM, but I'm hoping that there is
> some flexibility on this

There was not, since I argued many times to leave it out.
So unless you can show practically how it can work, I have my doubts
that we'll be allowed to go forward with this approach.

> and that future versions can defer to a
> utility that uses the ExceptionTypes Enum instance as the key to look
> up the internationalized template string.

Looks good.  Where is the code? ;-)

>>
>>> I think it satisfies everyone's requirements with:
>>> - A single MathException (No hierarchy)
>>
>> That would not satisfy everyone. :-!
>>
>>> - The ExceptionTypes Enum contains all the exception types
>>> - The ExceptionTypes Enum 'key' maps to the corresponding message 1
>>> to 1
>>> - The ExceptionFactory (Utility) throws exceptions, if necessary,
>>> that have always have a single unique root cause, such as NPEs
>>
>> I was wondering whether the "factory" idea could indeed satisfy
>> everyone.
>>
>> Rather than throwing the non-standard "MathException", the factory
>> would
>> generate one of the standard exceptions, constructed with the
>> internal
>> "MathException" as its cause:
> I think it's good that CM throws CM specific exceptions.  This way
> when I write the handler I can know that the exception is CM specific
> without having to unwrap it.

But if there are several CM exceptions hierarchies, the handler will
have
to check for every base type, leading to more code.

We could provide a utility:

public boolean isMathException(RuntimeException e) {
   if (e instanceof MathException) {
     return true;
   }
   final Throwable t = e.getCause();
   if (t != null) {
     if (e instanceof MathException) {
       return true;
     }
   }
   return false;
}

>>
>> public class ExceptionFactory {
>>
>>   public static void throwIllegalArgumentException(MathException e)
>> {
>>     throw new IllegalArgumentException(e);
>>   }
>>
>>   public static void throwNullPointerException(MathException e) {
>>     throw new NullPointerException(e);
>>   }
>>
>>   // And so on...
>> }
>>
>> So, CM code would be
>>
>> public class Algo {
>>
>>   public void evaluate(double value) {
>>     // Check precondition.
>>     final double min = computeMin();
>>     if (value < min) {
>>       final MathException e = new
>> MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE,
>> value);
>>       ExceptionFactory.throwIllegalArgumentException(e);
>>     }
>>
>>     // Precondition OK.
>>   }
>> }
> Another thing that I hinted to is that the the factory builds in the
> precondition check in the throw method.  So that the line:
>
>     if (value < min) {
>
> can be nixed.

It seems nice to ensure that the exception raised is consistent with
the
checked condition.

Then, a factory method like
   throwNotStrictlyPositiveException(Number value, String key)
should probably be renamed to
   checkNotStrictlyPositiveException(Number value, String key)

Also, shouldn't the "key" argument should be optional?

>>
>> Then, in an application's code:
>>
>> public void appMethod() {
>>   // ...
>>
>>   // Use CM.
>>   try {
>>     Algo a = new Algo();
>>     a.evaluate(2);
>>   } catch (IllegalArgumentException iae) {
>>     final Throwable cause = iae.getCause();
>>     if (cause instanceof MathException) {
>>       final MathException e = (MathException) cause;
>>
>>       // Rethrow an application-specific exception that will make
>> more sense
>>       // to my customers.
>>       throw new InvalidDataInputException(e.get(CONSTRAINT),
>> e.get(VALUE));
>>     }
>>   }
>> }
>>
>> This is all untested.
>> Did I miss something?
>
> I think you got it all...But the handler will be shorter if the
> exception is not wrapped.

But not significantly, I guess.
We could also provide

public MathException getMathException(RuntimeException e) {
   if (e instanceof MathException) {
     return (MathException) e;
   }
   final Throwable t = e.getCause();
   if (t != null) {
     if (e instanceof MathException) {
       return (MathException) e;
     }
   }
   return null;
}

And then define the other utility as:

public boolean isMathException(RuntimeException e) {
   return getMathException(e) != null;
}

> The pattern I'm used to is that libraries
> wrap the exceptions of other libraries in order to offer a
> standardized facade to the user.  For example Spring wraps Hibernate
> exceptions, since Spring is a layer on top of Hibernate and other
> data
> access providers.

What do they advertize?  Standard exception, possibly extended, or
specific ones, possibly belonging to single hierarchy?


Gilles

>>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

ole ersoy


On 12/22/2015 11:46 AM, Gilles wrote:

> Hi.
>
> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>> On 12/21/2015 06:44 PM, Gilles wrote:
>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>> Hi,
>>>>
>>>> I was considering jumping into the JDKRandomGenerator exception
>>>> discussion, but I did not want to hijack it.
>>>>
>>>> Not sure if any of you have had a chance to looks at this:
>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>
>>>>
>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>
>>> I had a rapid look; unfortunately not in sufficient details to
>>> grasp the major departures from the existing framework.
>>> Could you display one or two examples comparing CM and firefly?
>> In addition to what I summarized below one detail that I think is
>> important is that the ExceptionTypes enum allows for more exact
>> targeting of the exception root cause.  For instance right now I have
>> the following arithmetic exception types:
>>
>>     /**
>>      * MATH ARITHMETIC EXCEPTIONS
>>      */
>>     MAE("MAE"),
>>     MAE__INTEGER_OVERFLOW("MAE__INTEGER_OVERFLOW"),
>>     MAE__LONG_OVERFLOW("MAE__LONG_OVERFLOW"),
>>     MAE__OVERFLOW_IN_ADDITION("MAE__OVERFLOW_IN_ADDITION"),
>> MAE__OVERFLOW_IN_SUBTRACTION("MAE__OVERFLOW_IN_SUBTRACTION"),
>>     MAE__GCD_OVERFLOW_32_BITS("MAE__GCD_OVERFLOW_32_BITS"),
>>     MAE__GCD_OVERFLOW_64_BITS("MAE__GCD_OVERFLOW_64_BITS"),
>>     MAE__LCM_OVERFLOW_32_BITS("MAE__LCM_OVERFLOW_32_BITS"),
>>     MAE__LCM_OVERFLOW_64_BITS("MAE__LCM_OVERFLOW_64_BITS"),
>>     MAE__DIVISION_BY_ZERO("MAE__DIVISION_BY_ZERO"),
>
> Side remark: The argument to the enum element is the same as the enum
> element's name; is there a way to avoid the duplication (i.e. the string
> would be generated automatically)?
Good point!  Originally I was considering using numbers for each group of exceptions.  For example 100 for arithmetic exceptions, 200 for matrix exceptions, etc.  But I think strings are fine.  So now it's down to this:
https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/ExceptionTypes.java

     /**
      * MATH ARITHMETIC EXCEPTIONS
      */
     MAE,
     MAE__INTEGER_OVERFLOW,
     MAE__LONG_OVERFLOW,
     MAE__OVERFLOW_IN_ADDITION,
     MAE__OVERFLOW_IN_SUBTRACTION,
     MAE__GCD_OVERFLOW_32_BITS,
     MAE__GCD_OVERFLOW_64_BITS,
     MAE__LCM_OVERFLOW_32_BITS,
     MAE__LCM_OVERFLOW_64_BITS,
     MAE__DIVISION_BY_ZERO,
     ...

>
>> So by looking at the exception type we know exactly what the issue
>> is.
>> With this approach CM will always only have 1 exception.  If more
>> types are needed then just add another line to the ExceptionTypes
>> Enum.  The new type is used to look up the message template in the
>> I18N resource bundle.
>>
>>
>>>
>>> It looks neat.
>> Thanks :)
>>> But I did not see how localization is handled.
>>
>> I did leave localization out.  I think localization was a hard
>> requirement in earlier versions of CM, but I'm hoping that there is
>> some flexibility on this
>
> There was not, since I argued many times to leave it out.
> So unless you can show practically how it can work, I have my doubts
> that we'll be allowed to go forward with this approach.
>
>> and that future versions can defer to a
>> utility that uses the ExceptionTypes Enum instance as the key to look
>> up the internationalized template string.
>
> Looks good.  Where is the code? ;-)

So CM clients would:
catch(MathException e) {
     String exceptionTemplate = ResourceBundle.getBundle("cm.exception.templates", new Locale("en", "US")).getString(e.getType());
     String i18Nmessage = buildMessage(exceptionTemplate, e.getContext());
     ...
}

I can prototype that out more.  Just trying to get a feel for how viable the concept is first.

>
>>>
>>>> I think it satisfies everyone's requirements with:
>>>> - A single MathException (No hierarchy)
>>>
>>> That would not satisfy everyone. :-!
>>>
>>>> - The ExceptionTypes Enum contains all the exception types
>>>> - The ExceptionTypes Enum 'key' maps to the corresponding message 1 to 1
>>>> - The ExceptionFactory (Utility) throws exceptions, if necessary,
>>>> that have always have a single unique root cause, such as NPEs
>>>
>>> I was wondering whether the "factory" idea could indeed satisfy
>>> everyone.
>>>
>>> Rather than throwing the non-standard "MathException", the factory would
>>> generate one of the standard exceptions, constructed with the internal
>>> "MathException" as its cause:
>> I think it's good that CM throws CM specific exceptions.  This way
>> when I write the handler I can know that the exception is CM specific
>> without having to unwrap it.
>
> But if there are several CM exceptions hierarchies, the handler will have
> to check for every base type, leading to more code.
True dat - but if there are no CM exception hierarchies then they don't :).

>
> We could provide a utility:
>
> public boolean isMathException(RuntimeException e) {
>   if (e instanceof MathException) {
>     return true;
>   }
>   final Throwable t = e.getCause();
>   if (t != null) {
>     if (e instanceof MathException) {
>       return true;
>     }
>   }
>   return false;
> }

Or just not wrap.

>
>
>>>
>>> public class ExceptionFactory {
>>>
>>>   public static void throwIllegalArgumentException(MathException e) {
>>>     throw new IllegalArgumentException(e);
>>>   }
>>>
>>>   public static void throwNullPointerException(MathException e) {
>>>     throw new NullPointerException(e);
>>>   }
>>>
>>>   // And so on...
>>> }
>>>
>>> So, CM code would be
>>>
>>> public class Algo {
>>>
>>>   public void evaluate(double value) {
>>>     // Check precondition.
>>>     final double min = computeMin();
>>>     if (value < min) {
>>>       final MathException e = new MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE, value);
>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>     }
>>>
>>>     // Precondition OK.
>>>   }
>>> }
>> Another thing that I hinted to is that the the factory builds in the
>> precondition check in the throw method.  So that the line:
>>
>>     if (value < min) {
>>
>> can be nixed.
>
> It seems nice to ensure that the exception raised is consistent with the
> checked condition.
That's the idea.
>
> Then, a factory method like
>   throwNotStrictlyPositiveException(Number value, String key)
> should probably be renamed to
>   checkNotStrictlyPositiveException(Number value, String key)
'check' is good.  I'm going to change it to check.
>
> Also, shouldn't the "key" argument should be optional?
The key is used to initialize the exception context with the Number instance.  Different modules could have different keys.  For example the Arithmetic module has keys X and Y.  So if Y caused the exception then Y would be passed as the key.  So if we are checking both we would do this:
checkNotStrictlyPositiveException(x, X);
checkNotStrictlyPositiveException(y, Y);

>
>>>
>>> Then, in an application's code:
>>>
>>> public void appMethod() {
>>>   // ...
>>>
>>>   // Use CM.
>>>   try {
>>>     Algo a = new Algo();
>>>     a.evaluate(2);
>>>   } catch (IllegalArgumentException iae) {
>>>     final Throwable cause = iae.getCause();
>>>     if (cause instanceof MathException) {
>>>       final MathException e = (MathException) cause;
>>>
>>>       // Rethrow an application-specific exception that will make more sense
>>>       // to my customers.
>>>       throw new InvalidDataInputException(e.get(CONSTRAINT), e.get(VALUE));
>>>     }
>>>   }
>>> }
>>>
>>> This is all untested.
>>> Did I miss something?
>>
>> I think you got it all...But the handler will be shorter if the
>> exception is not wrapped.
>
> But not significantly, I guess.
> We could also provide
>
> public MathException getMathException(RuntimeException e) {
>   if (e instanceof MathException) {
>     return (MathException) e;
>   }
>   final Throwable t = e.getCause();
>   if (t != null) {
>     if (e instanceof MathException) {
>       return (MathException) e;
>     }
>   }
>   return null;
> }
>
> And then define the other utility as:
>
> public boolean isMathException(RuntimeException e) {
>   return getMathException(e) != null;
> }
>
>> The pattern I'm used to is that libraries
>> wrap the exceptions of other libraries in order to offer a
>> standardized facade to the user.  For example Spring wraps Hibernate
>> exceptions, since Spring is a layer on top of Hibernate and other data
>> access providers.
>
> What do they advertize?  Standard exception, possibly extended, or
> specific ones, possibly belonging to single hierarchy?
Spring namespaced - single hierarchy:
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/dao/DataAccessException.html

BTW - this is blue sky thinking - but Spring Boot has an @ExceptionHandler annotation that allows the developer to wire up an exception handler.  It might be worth exploring something similar for the purpose of automating I18N requirements.

@ExceptionHandler(MathException.class)
someClientCodeThatUsesCM();

Cheers,
Ole

[...]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Gilles Sadowski
In reply to this post by ole ersoy
On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:

> On 12/22/2015 11:46 AM, Gilles wrote:
>> Hi.
>>
>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>> Hi,
>>>>>
>>>>> I was considering jumping into the JDKRandomGenerator exception
>>>>> discussion, but I did not want to hijack it.
>>>>>
>>>>> Not sure if any of you have had a chance to looks at this:
>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>
>>>> [...]
>>>>
>>>> But I did not see how localization is handled.
>>>
>>> I did leave localization out.  I think localization was a hard
>>> requirement in earlier versions of CM, but I'm hoping that there is
>>> some flexibility on this
>>
>> There was not, since I argued many times to leave it out.
>> So unless you can show practically how it can work, I have my doubts
>> that we'll be allowed to go forward with this approach.
>>
>>> and that future versions can defer to a
>>> utility that uses the ExceptionTypes Enum instance as the key to
>>> look
>>> up the internationalized template string.
>>
>> Looks good.  Where is the code? ;-)
>
> So CM clients would:
> catch(MathException e) {
>     String exceptionTemplate =
> ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
> "US")).getString(e.getType());
>     String i18Nmessage = buildMessage(exceptionTemplate,
> e.getContext());
>     ...
> }
>
> I can prototype that out more.  Just trying to get a feel for how
> viable the concept is first.

I'm not sure I understand correctly.
Does that mean that
1. Uncaught exceptions will lead to a message in English?
2. Every "catch" must repeat the same calls (although the arguments are
likely
    to be the same for all clauses (and for all applications)?

Comparing this with the current behaviour (where the translated message
String
is created when "e.getLocalizedMessage()" is called) is likely to make
people
unhappy.

>>>>
>>>>> I think it satisfies everyone's requirements with:
>>>>> - A single MathException (No hierarchy)
>>>>
>>>> That would not satisfy everyone. :-!
>>>>
>>>>> - The ExceptionTypes Enum contains all the exception types
>>>>> - The ExceptionTypes Enum 'key' maps to the corresponding message
>>>>> 1 to 1
>>>>> - The ExceptionFactory (Utility) throws exceptions, if necessary,
>>>>> that have always have a single unique root cause, such as NPEs
>>>>
>>>> I was wondering whether the "factory" idea could indeed satisfy
>>>> everyone.
>>>>
>>>> Rather than throwing the non-standard "MathException", the factory
>>>> would
>>>> generate one of the standard exceptions, constructed with the
>>>> internal
>>>> "MathException" as its cause:
>>> I think it's good that CM throws CM specific exceptions.  This way
>>> when I write the handler I can know that the exception is CM
>>> specific
>>> without having to unwrap it.
>>
>> But if there are several CM exceptions hierarchies, the handler will
>> have
>> to check for every base type, leading to more code.
> True dat - but if there are no CM exception hierarchies then they
> don't :).

I'd be interested in settling the matter of whether we must use a
single
hierarchy because of technical limitations, or if it is a good solution
on its own, i.e. extending standard exceptions is not a better practice
after all.

>>
>> We could provide a utility:
>>
>> public boolean isMathException(RuntimeException e) {
>>   if (e instanceof MathException) {
>>     return true;
>>   }
>>   final Throwable t = e.getCause();
>>   if (t != null) {
>>     if (e instanceof MathException) {
>>       return true;
>>     }
>>   }
>>   return false;
>> }
>
> Or just not wrap.

Of course, but choosing one or the other is not a technical problem;
it's design decision.  Do we have arguments (or reference to them)?

>>>>
>>>> public class ExceptionFactory {
>>>>
>>>>   public static void throwIllegalArgumentException(MathException
>>>> e) {
>>>>     throw new IllegalArgumentException(e);
>>>>   }
>>>>
>>>>   public static void throwNullPointerException(MathException e) {
>>>>     throw new NullPointerException(e);
>>>>   }
>>>>
>>>>   // And so on...
>>>> }
>>>>
>>>> So, CM code would be
>>>>
>>>> public class Algo {
>>>>
>>>>   public void evaluate(double value) {
>>>>     // Check precondition.
>>>>     final double min = computeMin();
>>>>     if (value < min) {
>>>>       final MathException e = new
>>>> MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE,
>>>> value);
>>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>>     }
>>>>
>>>>     // Precondition OK.
>>>>   }
>>>> }
>>> Another thing that I hinted to is that the the factory builds in
>>> the
>>> precondition check in the throw method.  So that the line:
>>>
>>>     if (value < min) {
>>>
>>> can be nixed.
>>
>> It seems nice to ensure that the exception raised is consistent with
>> the
>> checked condition.
> That's the idea.

OK, but do you foresee that all precondition checks will be handle by
factory methods.
It would not be so nice to have explicit checks sprinkled here and
there.

>>
>> Then, a factory method like
>>   throwNotStrictlyPositiveException(Number value, String key)
>> should probably be renamed to
>>   checkNotStrictlyPositiveException(Number value, String key)
> 'check' is good.  I'm going to change it to check.
>>
>> Also, shouldn't the "key" argument should be optional?
> The key is used to initialize the exception context with the Number
> instance.  Different modules could have different keys.  For example
> the Arithmetic module has keys X and Y.  So if Y caused the exception
> then Y would be passed as the key.  So if we are checking both we
> would do this:
> checkNotStrictlyPositiveException(x, X);
> checkNotStrictlyPositiveException(y, Y);
>>
>>>>
>>>> Then, in an application's code:
>>>>
>>>> public void appMethod() {
>>>>   // ...
>>>>
>>>>   // Use CM.
>>>>   try {
>>>>     Algo a = new Algo();
>>>>     a.evaluate(2);
>>>>   } catch (IllegalArgumentException iae) {
>>>>     final Throwable cause = iae.getCause();
>>>>     if (cause instanceof MathException) {
>>>>       final MathException e = (MathException) cause;
>>>>
>>>>       // Rethrow an application-specific exception that will make
>>>> more sense
>>>>       // to my customers.
>>>>       throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>> e.get(VALUE));
>>>>     }
>>>>   }
>>>> }
>>>>
>>>> This is all untested.
>>>> Did I miss something?
>>>
>>> I think you got it all...But the handler will be shorter if the
>>> exception is not wrapped.
>>
>> But not significantly, I guess.
>> We could also provide
>>
>> public MathException getMathException(RuntimeException e) {
>>   if (e instanceof MathException) {
>>     return (MathException) e;
>>   }
>>   final Throwable t = e.getCause();
>>   if (t != null) {
>>     if (e instanceof MathException) {
>>       return (MathException) e;
>>     }
>>   }
>>   return null;
>> }
>>
>> And then define the other utility as:
>>
>> public boolean isMathException(RuntimeException e) {
>>   return getMathException(e) != null;
>> }
>>
>>> The pattern I'm used to is that libraries
>>> wrap the exceptions of other libraries in order to offer a
>>> standardized facade to the user.  For example Spring wraps
>>> Hibernate
>>> exceptions, since Spring is a layer on top of Hibernate and other
>>> data
>>> access providers.
>>
>> What do they advertize?  Standard exception, possibly extended, or
>> specific ones, possibly belonging to single hierarchy?
> Spring namespaced - single hierarchy:
>
> http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/dao/DataAccessException.html
>
> BTW - this is blue sky thinking - but Spring Boot has an
> @ExceptionHandler annotation that allows the developer to wire up an
> exception handler.  It might be worth exploring something similar for
> the purpose of automating I18N requirements.
>
> @ExceptionHandler(MathException.class)
> someClientCodeThatUsesCM();


That would be quite necessary I'm afraid. ;-)

Best regards,
Gilles

>
> Cheers,
> Ole



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Luc Maisonobe-2
Le 2015-12-23 01:41, Gilles a écrit :

> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>> On 12/22/2015 11:46 AM, Gilles wrote:
>>> Hi.
>>>
>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I was considering jumping into the JDKRandomGenerator exception
>>>>>> discussion, but I did not want to hijack it.
>>>>>>
>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>
>>>>> [...]
>>>>>
>>>>> But I did not see how localization is handled.
>>>>
>>>> I did leave localization out.  I think localization was a hard
>>>> requirement in earlier versions of CM, but I'm hoping that there is
>>>> some flexibility on this
>>>
>>> There was not, since I argued many times to leave it out.
>>> So unless you can show practically how it can work, I have my doubts
>>> that we'll be allowed to go forward with this approach.
>>>
>>>> and that future versions can defer to a
>>>> utility that uses the ExceptionTypes Enum instance as the key to
>>>> look
>>>> up the internationalized template string.
>>>
>>> Looks good.  Where is the code? ;-)
>>
>> So CM clients would:
>> catch(MathException e) {
>>     String exceptionTemplate =
>> ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
>> "US")).getString(e.getType());
>>     String i18Nmessage = buildMessage(exceptionTemplate,
>> e.getContext());
>>     ...
>> }
>>
>> I can prototype that out more.  Just trying to get a feel for how
>> viable the concept is first.
>
> I'm not sure I understand correctly.
> Does that mean that
> 1. Uncaught exceptions will lead to a message in English?
> 2. Every "catch" must repeat the same calls (although the arguments are
> likely
>    to be the same for all clauses (and for all applications)?
>
> Comparing this with the current behaviour (where the translated message
> String
> is created when "e.getLocalizedMessage()" is called) is likely to make
> people
> unhappy.

This could be made simpler with some task delegating between user code
and CM code.
What about :

  interface ExceptionLocalizer {
     /** Localize an exception message.
       * @param locale locale to use
       * @param me exception to localize
       * @return localized message for the exception
       */
     String localize(Locale locale, MathException me);
  }

and having ExceptionFactory hold a user-provided implementation of this
interface?

  public class ExceptionFactory {

    private static ExceptionLocalizer localizer = new NoOpLocalizer();

    public static setLocalizer(ExceptionLocalizer l) {
       localizer = l;
    }

    public static String localize(Locale locale, MathException me) {
      return localizer.localize(locale, me);
    }

    /** Default implementation of the localizer that does nothing. */
    private static class NoOpLocalizer implements ExceptionLocalizer {
           /** {@inheritDoc} */
           @Override
           public String localize(MathException me) {
            return me.getMessage();
          }
    }

  }

and MathException could implement both getLocalizedMessage() and
even getMessage(Locale) by delegating to the user code:

   public class MathException {

     public String getLocalizedMessage() {
       return ExceptionFactory.localize(Locale.getDefault(), this);
     }

     public String getMessage(Locale locale) {
       return ExceptionFactory.localize(locale, this);
     }

     ...

   }

One thing that would be nice would be that in addition to the get
method,
MathException also provides a getKeys to retrieve all keys and a getType
to retrieve the type. The later correspond to the getPatern (or
getLocalizable)
I asked for a few years ago in ExceptionContext. The point for these
methods
is that if we provide users a way to retrieve the parameters that were
used
in the exception construction, then we can delegate localization to
users
as they can do their own code that will rebuild a complete meaasage as
they
want. When you have only the keys and they have reused names like
OPERATOR
or VECTOR, it can't be delegated.

Note that this is independent of the fact there is one or several
hierarchies.
If there are several ones, the two one-liners above must simply be
copied
(yeah, code duplication, I know).

>
>>>>>
>>>>>> I think it satisfies everyone's requirements with:
>>>>>> - A single MathException (No hierarchy)
>>>>>
>>>>> That would not satisfy everyone. :-!
>>>>>
>>>>>> - The ExceptionTypes Enum contains all the exception types
>>>>>> - The ExceptionTypes Enum 'key' maps to the corresponding message
>>>>>> 1 to 1
>>>>>> - The ExceptionFactory (Utility) throws exceptions, if necessary,
>>>>>> that have always have a single unique root cause, such as NPEs
>>>>>
>>>>> I was wondering whether the "factory" idea could indeed satisfy
>>>>> everyone.
>>>>>
>>>>> Rather than throwing the non-standard "MathException", the factory
>>>>> would
>>>>> generate one of the standard exceptions, constructed with the
>>>>> internal
>>>>> "MathException" as its cause:
>>>> I think it's good that CM throws CM specific exceptions.  This way
>>>> when I write the handler I can know that the exception is CM
>>>> specific
>>>> without having to unwrap it.
>>>
>>> But if there are several CM exceptions hierarchies, the handler will
>>> have
>>> to check for every base type, leading to more code.
>> True dat - but if there are no CM exception hierarchies then they
>> don't :).
>
> I'd be interested in settling the matter of whether we must use a
> single
> hierarchy because of technical limitations, or if it is a good solution
> on its own, i.e. extending standard exceptions is not a better practice
> after all.
>
>>>
>>> We could provide a utility:
>>>
>>> public boolean isMathException(RuntimeException e) {
>>>   if (e instanceof MathException) {
>>>     return true;
>>>   }
>>>   final Throwable t = e.getCause();
>>>   if (t != null) {
>>>     if (e instanceof MathException) {
>>>       return true;
>>>     }
>>>   }
>>>   return false;
>>> }
>>
>> Or just not wrap.
>
> Of course, but choosing one or the other is not a technical problem;
> it's design decision.  Do we have arguments (or reference to them)?
>
>>>>>
>>>>> public class ExceptionFactory {
>>>>>
>>>>>   public static void throwIllegalArgumentException(MathException e)
>>>>> {
>>>>>     throw new IllegalArgumentException(e);
>>>>>   }
>>>>>
>>>>>   public static void throwNullPointerException(MathException e) {
>>>>>     throw new NullPointerException(e);
>>>>>   }
>>>>>
>>>>>   // And so on...
>>>>> }
>>>>>
>>>>> So, CM code would be
>>>>>
>>>>> public class Algo {
>>>>>
>>>>>   public void evaluate(double value) {
>>>>>     // Check precondition.
>>>>>     final double min = computeMin();
>>>>>     if (value < min) {
>>>>>       final MathException e = new
>>>>> MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE,
>>>>> value);
>>>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>>>     }
>>>>>
>>>>>     // Precondition OK.
>>>>>   }
>>>>> }
>>>> Another thing that I hinted to is that the the factory builds in the
>>>> precondition check in the throw method.  So that the line:
>>>>
>>>>     if (value < min) {
>>>>
>>>> can be nixed.
>>>
>>> It seems nice to ensure that the exception raised is consistent with
>>> the
>>> checked condition.
>> That's the idea.
>
> OK, but do you foresee that all precondition checks will be handle by
> factory methods.
> It would not be so nice to have explicit checks sprinkled here and
> there.
>
>>>
>>> Then, a factory method like
>>>   throwNotStrictlyPositiveException(Number value, String key)
>>> should probably be renamed to
>>>   checkNotStrictlyPositiveException(Number value, String key)
>> 'check' is good.  I'm going to change it to check.

as the name was changed to checkSomething, the last part Exception in
the name could be dropped.

>>>
>>> Also, shouldn't the "key" argument should be optional?
>> The key is used to initialize the exception context with the Number
>> instance.  Different modules could have different keys.  For example
>> the Arithmetic module has keys X and Y.  So if Y caused the exception
>> then Y would be passed as the key.  So if we are checking both we
>> would do this:
>> checkNotStrictlyPositiveException(x, X);
>> checkNotStrictlyPositiveException(y, Y);
>>>
>>>>>
>>>>> Then, in an application's code:
>>>>>
>>>>> public void appMethod() {
>>>>>   // ...
>>>>>
>>>>>   // Use CM.
>>>>>   try {
>>>>>     Algo a = new Algo();
>>>>>     a.evaluate(2);
>>>>>   } catch (IllegalArgumentException iae) {
>>>>>     final Throwable cause = iae.getCause();
>>>>>     if (cause instanceof MathException) {
>>>>>       final MathException e = (MathException) cause;
>>>>>
>>>>>       // Rethrow an application-specific exception that will make
>>>>> more sense
>>>>>       // to my customers.
>>>>>       throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>>> e.get(VALUE));
>>>>>     }
>>>>>   }
>>>>> }
>>>>>
>>>>> This is all untested.
>>>>> Did I miss something?

In the code above, if the iae does not have a cause, or if it is not a
MathException,
the iae should be rethrown.

>>>>
>>>> I think you got it all...But the handler will be shorter if the
>>>> exception is not wrapped.
>>>
>>> But not significantly, I guess.
>>> We could also provide
>>>
>>> public MathException getMathException(RuntimeException e) {
>>>   if (e instanceof MathException) {
>>>     return (MathException) e;
>>>   }
>>>   final Throwable t = e.getCause();
>>>   if (t != null) {
>>>     if (e instanceof MathException) {
>>>       return (MathException) e;
>>>     }
>>>   }
>>>   return null;
>>> }
>>>
>>> And then define the other utility as:
>>>
>>> public boolean isMathException(RuntimeException e) {
>>>   return getMathException(e) != null;
>>> }
>>>
>>>> The pattern I'm used to is that libraries
>>>> wrap the exceptions of other libraries in order to offer a
>>>> standardized facade to the user.  For example Spring wraps Hibernate
>>>> exceptions, since Spring is a layer on top of Hibernate and other
>>>> data
>>>> access providers.
>>>
>>> What do they advertize?  Standard exception, possibly extended, or
>>> specific ones, possibly belonging to single hierarchy?
>> Spring namespaced - single hierarchy:
>>
>> http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/dao/DataAccessException.html
>>
>> BTW - this is blue sky thinking - but Spring Boot has an
>> @ExceptionHandler annotation that allows the developer to wire up an
>> exception handler.  It might be worth exploring something similar for
>> the purpose of automating I18N requirements.
>>
>> @ExceptionHandler(MathException.class)
>> someClientCodeThatUsesCM();
>
>
> That would be quite necessary I'm afraid. ;-)

Not necessarily. The above support for I18N is quite simple.


best regards,
Luc

>
> Best regards,
> Gilles
>
>>
>> Cheers,
>> Ole
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Gilles Sadowski
Hello.

On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:

> Le 2015-12-23 01:41, Gilles a écrit :
>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>> Hi.
>>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>>> Hi,
>>>>>>> I was considering jumping into the JDKRandomGenerator exception
>>>>>>> discussion, but I did not want to hijack it.
>>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>> [...]
>>>>>> But I did not see how localization is handled.
>>>>> I did leave localization out.  I think localization was a hard
>>>>> requirement in earlier versions of CM, but I'm hoping that there
>>>>> is
>>>>> some flexibility on this
>>>> There was not, since I argued many times to leave it out.
>>>> So unless you can show practically how it can work, I have my
>>>> doubts
>>>> that we'll be allowed to go forward with this approach.
>>>>
>>>>> and that future versions can defer to a
>>>>> utility that uses the ExceptionTypes Enum instance as the key to
>>>>> look
>>>>> up the internationalized template string.
>>>> Looks good.  Where is the code? ;-)
>>> So CM clients would:
>>> catch(MathException e) {
>>>     String exceptionTemplate =
>>> ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
>>> "US")).getString(e.getType());
>>>     String i18Nmessage = buildMessage(exceptionTemplate,
>>> e.getContext());
>>>     ...
>>> }
>>> I can prototype that out more.  Just trying to get a feel for how
>>> viable the concept is first.
>> I'm not sure I understand correctly.
>> Does that mean that
>> 1. Uncaught exceptions will lead to a message in English?
>> 2. Every "catch" must repeat the same calls (although the arguments
>> are likely
>>    to be the same for all clauses (and for all applications)?
>> Comparing this with the current behaviour (where the translated
>> message String
>> is created when "e.getLocalizedMessage()" is called) is likely to
>> make people
>> unhappy.
>
> This could be made simpler with some task delegating between user
> code and CM code.
> What about :
>
>  interface ExceptionLocalizer {
>     /** Localize an exception message.
>       * @param locale locale to use
>       * @param me exception to localize
>       * @return localized message for the exception
>       */
>     String localize(Locale locale, MathException me);
>  }
>
> and having ExceptionFactory hold a user-provided implementation of
> this interface?
>
>  public class ExceptionFactory {
>
>    private static ExceptionLocalizer localizer = new NoOpLocalizer();
>
>    public static setLocalizer(ExceptionLocalizer l) {
>       localizer = l;
>    }

I think that this is potentially dangerous for two reasons (if I'm
not mistaken): it's not thread-safe and it can be called by any
library used by the main application.

I think that the "localizer" instance must be obtained in a way which
the end-user controls.

>
>    public static String localize(Locale locale, MathException me) {
>      return localizer.localize(locale, me);
>    }
>
>    /** Default implementation of the localizer that does nothing. */
>    private static class NoOpLocalizer implements ExceptionLocalizer {
>           /** {@inheritDoc} */
>           @Override
>           public String localize(MathException me) {
>            return me.getMessage();
>          }
>    }
>
>  }
>
> and MathException could implement both getLocalizedMessage() and
> even getMessage(Locale) by delegating to the user code:
>
>   public class MathException {
>
>     public String getLocalizedMessage() {
>       return ExceptionFactory.localize(Locale.getDefault(), this);
>     }
>
>     public String getMessage(Locale locale) {
>       return ExceptionFactory.localize(locale, this);
>     }
>
>     ...
>
>   }
>
> One thing that would be nice would be that in addition to the get
> method,
> MathException also provides a getKeys to retrieve all keys and a
> getType
> to retrieve the type. The later correspond to the getPatern (or
> getLocalizable)
> I asked for a few years ago in ExceptionContext. The point for these
> methods
> is that if we provide users a way to retrieve the parameters that
> were used
> in the exception construction, then we can delegate localization to
> users
> as they can do their own code that will rebuild a complete meaasage
> as they
> want. When you have only the keys and they have reused names like
> OPERATOR
> or VECTOR, it can't be delegated.

If those are available (as suggested in Ole's example above), would you
indeed
be OK that localization is not a CM concern anymore?

We could provide code of how to perform the translation in the
userguide.

> Note that this is independent of the fact there is one or several
> hierarchies.
> If there are several ones, the two one-liners above must simply be
> copied
> (yeah, code duplication, I know).
>
>>
>>>>>>
>>>>>>> I think it satisfies everyone's requirements with:
>>>>>>> - A single MathException (No hierarchy)
>>>>>> That would not satisfy everyone. :-!
>>>>>>
>>>>>>> - The ExceptionTypes Enum contains all the exception types
>>>>>>> - The ExceptionTypes Enum 'key' maps to the corresponding
>>>>>>> message 1 to 1
>>>>>>> - The ExceptionFactory (Utility) throws exceptions, if
>>>>>>> necessary,
>>>>>>> that have always have a single unique root cause, such as NPEs
>>>>>> I was wondering whether the "factory" idea could indeed satisfy
>>>>>> everyone.
>>>>>> Rather than throwing the non-standard "MathException", the
>>>>>> factory would
>>>>>> generate one of the standard exceptions, constructed with the
>>>>>> internal
>>>>>> "MathException" as its cause:
>>>>> I think it's good that CM throws CM specific exceptions.  This
>>>>> way
>>>>> when I write the handler I can know that the exception is CM
>>>>> specific
>>>>> without having to unwrap it.
>>>> But if there are several CM exceptions hierarchies, the handler
>>>> will have
>>>> to check for every base type, leading to more code.
>>> True dat - but if there are no CM exception hierarchies then they
>>> don't :).
>> I'd be interested in settling the matter of whether we must use a
>> single
>> hierarchy because of technical limitations, or if it is a good
>> solution
>> on its own, i.e. extending standard exceptions is not a better
>> practice
>> after all.
>>
>>>> We could provide a utility:
>>>> public boolean isMathException(RuntimeException e) {
>>>>   if (e instanceof MathException) {
>>>>     return true;
>>>>   }
>>>>   final Throwable t = e.getCause();
>>>>   if (t != null) {
>>>>     if (e instanceof MathException) {
>>>>       return true;
>>>>     }
>>>>   }
>>>>   return false;
>>>> }
>>> Or just not wrap.
>> Of course, but choosing one or the other is not a technical problem;
>> it's design decision.  Do we have arguments (or reference to them)?
>>
>>>>>> public class ExceptionFactory {
>>>>>> public static void throwIllegalArgumentException(MathException
>>>>>> e) {
>>>>>>     throw new IllegalArgumentException(e);
>>>>>>   }
>>>>>> public static void throwNullPointerException(MathException e) {
>>>>>>     throw new NullPointerException(e);
>>>>>>   }
>>>>>> // And so on...
>>>>>> }
>>>>>> So, CM code would be
>>>>>> public class Algo {
>>>>>> public void evaluate(double value) {
>>>>>>     // Check precondition.
>>>>>>     final double min = computeMin();
>>>>>>     if (value < min) {
>>>>>>       final MathException e = new
>>>>>> MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE,
>>>>>> value);
>>>>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>>>>     }
>>>>>> // Precondition OK.
>>>>>>   }
>>>>>> }
>>>>> Another thing that I hinted to is that the the factory builds in
>>>>> the
>>>>> precondition check in the throw method.  So that the line:
>>>>> if (value < min) {
>>>>> can be nixed.
>>>> It seems nice to ensure that the exception raised is consistent
>>>> with the
>>>> checked condition.
>>> That's the idea.
>> OK, but do you foresee that all precondition checks will be handle
>> by
>> factory methods.
>> It would not be so nice to have explicit checks sprinkled here and
>> there.
>>
>>>> Then, a factory method like
>>>>   throwNotStrictlyPositiveException(Number value, String key)
>>>> should probably be renamed to
>>>>   checkNotStrictlyPositiveException(Number value, String key)
>>> 'check' is good.  I'm going to change it to check.
>
> as the name was changed to checkSomething, the last part Exception in
> the name could be dropped.
>
>>>> Also, shouldn't the "key" argument should be optional?
>>> The key is used to initialize the exception context with the Number
>>> instance.  Different modules could have different keys.  For
>>> example
>>> the Arithmetic module has keys X and Y.  So if Y caused the
>>> exception
>>> then Y would be passed as the key.  So if we are checking both we
>>> would do this:
>>> checkNotStrictlyPositiveException(x, X);
>>> checkNotStrictlyPositiveException(y, Y);
>>>>
>>>>>> Then, in an application's code:
>>>>>> public void appMethod() {
>>>>>>   // ...
>>>>>> // Use CM.
>>>>>>   try {
>>>>>>     Algo a = new Algo();
>>>>>>     a.evaluate(2);
>>>>>>   } catch (IllegalArgumentException iae) {
>>>>>>     final Throwable cause = iae.getCause();
>>>>>>     if (cause instanceof MathException) {
>>>>>>       final MathException e = (MathException) cause;
>>>>>> // Rethrow an application-specific exception that will make more
>>>>>> sense
>>>>>>       // to my customers.
>>>>>>       throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>>>> e.get(VALUE));
>>>>>>     }
>>>>>>   }
>>>>>> }
>>>>>> This is all untested.
>>>>>> Did I miss something?
>
> In the code above, if the iae does not have a cause, or if it is not
> a MathException,
> the iae should be rethrown.

Indeed!
The updated code (also unstested):

    try {
      Algo a = new Algo();
      a.evaluate(2);
    } catch (IllegalArgumentException iae) {
      final MathException e = ExceptionFactory.getMathException(iae);

      if (e != null) {
        // Rethrow an application-specific exception that will make more
sense
        // to my customers.
        throw new InvalidDataInputException(e.get(CONSTRAINT),
e.get(VALUE));
      } else {
        throw iae;
      }
    }

>>>>> I think you got it all...But the handler will be shorter if the
>>>>> exception is not wrapped.
>>>> But not significantly, I guess.
>>>> We could also provide
>>>> public MathException getMathException(RuntimeException e) {
>>>>   if (e instanceof MathException) {
>>>>     return (MathException) e;
>>>>   }
>>>>   final Throwable t = e.getCause();
>>>>   if (t != null) {
>>>>     if (e instanceof MathException) {
>>>>       return (MathException) e;
>>>>     }
>>>>   }
>>>>   return null;
>>>> }
>>>> And then define the other utility as:
>>>> public boolean isMathException(RuntimeException e) {
>>>>   return getMathException(e) != null;
>>>> }
>>>>
>>>>> The pattern I'm used to is that libraries
>>>>> wrap the exceptions of other libraries in order to offer a
>>>>> standardized facade to the user.  For example Spring wraps
>>>>> Hibernate
>>>>> exceptions, since Spring is a layer on top of Hibernate and other
>>>>> data
>>>>> access providers.
>>>> What do they advertize?  Standard exception, possibly extended, or
>>>> specific ones, possibly belonging to single hierarchy?
>>> Spring namespaced - single hierarchy:
>>>
>>> http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/dao/DataAccessException.html
>>> BTW - this is blue sky thinking - but Spring Boot has an
>>> @ExceptionHandler annotation that allows the developer to wire up
>>> an
>>> exception handler.  It might be worth exploring something similar
>>> for
>>> the purpose of automating I18N requirements.
>>> @ExceptionHandler(MathException.class)
>>> someClientCodeThatUsesCM();
>>
>> That would be quite necessary I'm afraid. ;-)
>
> Not necessarily. The above support for I18N is quite simple.

Maybe too simple... ;-)
[What did they say about global variables?]

Best regards,
Gilles

>
> best regards,
> Luc
>
>> Best regards,
>> Gilles
>>
>>> Cheers,
>>> Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

ole ersoy
In reply to this post by Gilles Sadowski
[...]

>>>
>>> Looks good.  Where is the code? ;-)
>>
>> So CM clients would:
>> catch(MathException e) {
>>     String exceptionTemplate = ResourceBundle.getBundle("cm.exception.templates", new Locale("en", "US")).getString(e.getType());
>>     String i18Nmessage = buildMessage(exceptionTemplate, e.getContext());
>>     ...
>> }
>>
>> I can prototype that out more.  Just trying to get a feel for how
>> viable the concept is first.
>
> I'm not sure I understand correctly.
> Does that mean that
> 1. Uncaught exceptions will lead to a message in English?
Sort of - Right now the exception message is just the Enum 'type/code'.  For example: MIA__INTEGER_OVERFLOW.  Calling toString() on the exception will produce a more detailed message with the context parameters as well.

>
> 2. Every "catch" must repeat the same calls (although the arguments are likely
>    to be the same for all clauses (and for all applications)?

Well - Suppose the use case is using CM to just write quick simulations in the main block.  We don't want to bother the analyst with what exceptions mean or throw catch concepts, etc.  So primarily the user is concerned with the //CM code block below:

public static void main(String args[]) {
    //The CM code...
}

So instead of providing the above block as a starting point this block would be provided:

public static void main(String args[]) {
    try {
    //The CM code...

} catch(MathException) {
    u.rethrowLocalized(e)
}


>
> Comparing this with the current behaviour (where the translated message String
> is created when "e.getLocalizedMessage()" is called) is likely to make people
> unhappy.
Hopefully they would be OK with something like the above.  If a single MathException is adopted it should be very easy to create a Cheatsheet with all the exception codes that can occur in a given scenario along with what it means in a language, in addition to handling it with the type of utility describe above.  I would think the goal would be to get the user to understand the exceptions as they are thrown in Java vernacular though...Even if I see an exception message in Norwegian I still need to read the code and Javadoc to figure out what it means.

I'm still looking into the possibility of a custom designed annotation to do the above utility, but it may require the use of AspectJ or Apache Weaver.

>
>
>> [...]
>
> I'd be interested in settling the matter of whether we must use a single
> hierarchy because of technical limitations, or if it is a good solution
> on its own, i.e. extending standard exceptions is not a better practice
> after all.
I think we understand this, but anything other than a single exception is going to introduce a non trivial amount of additional effort both for users, maintainers, and documenters.  Consider the ripple effect this has on other libraries using CM.

>
>>>
>>> We could provide a utility:
>>>
>>> public boolean isMathException(RuntimeException e) {
>>>   if (e instanceof MathException) {
>>>     return true;
>>>   }
>>>   final Throwable t = e.getCause();
>>>   if (t != null) {
>>>     if (e instanceof MathException) {
>>>       return true;
>>>     }
>>>   }
>>>   return false;
>>> }
>>
>> Or just not wrap.
>
> Of course, but choosing one or the other is not a technical problem;
> it's design decision.  Do we have arguments (or reference to them)?

As Luke pointed out, we want to be able to catch the exception and know that it came from CM with minimal effort.  If another layer is using CM, then that layer should catch the CM exception and rethrow it using a System exception providing a global facade the same way Spring does.

>
>>>>>
>>>>> public class ExceptionFactory {
>>>>>
>>>>>   public static void throwIllegalArgumentException(MathException e) {
>>>>>     throw new IllegalArgumentException(e);
>>>>>   }
>>>>>
>>>>>   public static void throwNullPointerException(MathException e) {
>>>>>     throw new NullPointerException(e);
>>>>>   }
>>>>>
>>>>>   // And so on...
>>>>> }
>>>>>
>>>>> So, CM code would be
>>>>>
>>>>> public class Algo {
>>>>>
>>>>>   public void evaluate(double value) {
>>>>>     // Check precondition.
>>>>>     final double min = computeMin();
>>>>>     if (value < min) {
>>>>>       final MathException e = new MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE, value);
>>>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>>>     }
>>>>>
>>>>>     // Precondition OK.
>>>>>   }
>>>>> }
>>>> Another thing that I hinted to is that the the factory builds in the
>>>> precondition check in the throw method.  So that the line:
>>>>
>>>>     if (value < min) {
>>>>
>>>> can be nixed.
>>>
>>> It seems nice to ensure that the exception raised is consistent with the
>>> checked condition.
>> That's the idea.
>
> OK, but do you foresee that all precondition checks will be handle by
> factory methods.
It would be nice.  Like you said, it's also good if an exception is always produced by a globally unique condition.
>
> It would not be so nice to have explicit checks sprinkled here and there.
Indeed.  The single exception design should allow for a factory method for all the Enum types.  If it's done right the factory should also make writing the utility for localizing messages easier.

[...]

Cheers,
Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

ole ersoy
In reply to this post by Luc Maisonobe-2

[...]

On 12/23/2015 03:38 AM, luc wrote:

>  interface ExceptionLocalizer {
>     /** Localize an exception message.
>       * @param locale locale to use
>       * @param me exception to localize
>       * @return localized message for the exception
>       */
>     String localize(Locale locale, MathException me);
>  }
>
> and having ExceptionFactory hold a user-provided implementation of this interface?
>
>  public class ExceptionFactory {
>
>    private static ExceptionLocalizer localizer = new NoOpLocalizer();
>
>    public static setLocalizer(ExceptionLocalizer l) {
>       localizer = l;
>    }
>
>    public static String localize(Locale locale, MathException me) {
>      return localizer.localize(locale, me);
>    }
>
>    /** Default implementation of the localizer that does nothing. */
>    private static class NoOpLocalizer implements ExceptionLocalizer {
>           /** {@inheritDoc} */
>           @Override
>           public String localize(MathException me) {
>            return me.getMessage();
>          }
>    }
>
>  }
>
> and MathException could implement both getLocalizedMessage() and
> even getMessage(Locale) by delegating to the user code:
>
>   public class MathException {
>
>     public String getLocalizedMessage() {
>       return ExceptionFactory.localize(Locale.getDefault(), this);
>     }
>
>     public String getMessage(Locale locale) {
>       return ExceptionFactory.localize(locale, this);
>     }
>
>     ...
>
>   }
>
Nice!

> One thing that would be nice would be that in addition to the get method,
> MathException also provides a getKeys to retrieve all keys and a getType
> to retrieve the type.

Just added getKeys() (Line 48):
https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java

getType() already there (Line 29 - @Getter annotation produces the getter)

Also added getMethodName() and getClassName() to get the source of the exception.  Since there is only a single exception there is no need to unroll it to get the root cause.

[...]

Cheers,
Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Luc Maisonobe-2
In reply to this post by Gilles Sadowski
Le 23/12/2015 14:32, Gilles a écrit :

> Hello.
>
> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>> Le 2015-12-23 01:41, Gilles a écrit :
>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>>> Hi.
>>>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>>>> Hi,
>>>>>>>> I was considering jumping into the JDKRandomGenerator exception
>>>>>>>> discussion, but I did not want to hijack it.
>>>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>>>>
>>>>>>> [...]
>>>>>>> But I did not see how localization is handled.
>>>>>> I did leave localization out.  I think localization was a hard
>>>>>> requirement in earlier versions of CM, but I'm hoping that there is
>>>>>> some flexibility on this
>>>>> There was not, since I argued many times to leave it out.
>>>>> So unless you can show practically how it can work, I have my doubts
>>>>> that we'll be allowed to go forward with this approach.
>>>>>
>>>>>> and that future versions can defer to a
>>>>>> utility that uses the ExceptionTypes Enum instance as the key to look
>>>>>> up the internationalized template string.
>>>>> Looks good.  Where is the code? ;-)
>>>> So CM clients would:
>>>> catch(MathException e) {
>>>>     String exceptionTemplate =
>>>> ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
>>>> "US")).getString(e.getType());
>>>>     String i18Nmessage = buildMessage(exceptionTemplate,
>>>> e.getContext());
>>>>     ...
>>>> }
>>>> I can prototype that out more.  Just trying to get a feel for how
>>>> viable the concept is first.
>>> I'm not sure I understand correctly.
>>> Does that mean that
>>> 1. Uncaught exceptions will lead to a message in English?
>>> 2. Every "catch" must repeat the same calls (although the arguments
>>> are likely
>>>    to be the same for all clauses (and for all applications)?
>>> Comparing this with the current behaviour (where the translated
>>> message String
>>> is created when "e.getLocalizedMessage()" is called) is likely to
>>> make people
>>> unhappy.
>>
>> This could be made simpler with some task delegating between user
>> code and CM code.
>> What about :
>>
>>  interface ExceptionLocalizer {
>>     /** Localize an exception message.
>>       * @param locale locale to use
>>       * @param me exception to localize
>>       * @return localized message for the exception
>>       */
>>     String localize(Locale locale, MathException me);
>>  }
>>
>> and having ExceptionFactory hold a user-provided implementation of
>> this interface?
>>
>>  public class ExceptionFactory {
>>
>>    private static ExceptionLocalizer localizer = new NoOpLocalizer();
>>
>>    public static setLocalizer(ExceptionLocalizer l) {
>>       localizer = l;
>>    }
>
> I think that this is potentially dangerous for two reasons (if I'm
> not mistaken): it's not thread-safe and it can be called by any
> library used by the main application.

Intermedaite libraries could also call it, and I hope they would be
designed to use a consistent way for their own exception (they should
let the user specify the localization mechanism, use it for themselves
and pass the configuration to CM).

Thread safety here is really not a concern (but we could protect it
if desired). This setting is a configuration level setting, it is
usually done once near the beginning of the main program. You don't
change the mechanism every millisecond.

>
> I think that the "localizer" instance must be obtained in a way which
> the end-user controls.

The user controls it. The setLocalizer method can be called directly by
user, and in fact I expect the user to do it.

>
>>
>>    public static String localize(Locale locale, MathException me) {
>>      return localizer.localize(locale, me);
>>    }
>>
>>    /** Default implementation of the localizer that does nothing. */
>>    private static class NoOpLocalizer implements ExceptionLocalizer {
>>           /** {@inheritDoc} */
>>           @Override
>>           public String localize(MathException me) {
>>            return me.getMessage();
>>          }
>>    }
>>
>>  }
>>
>> and MathException could implement both getLocalizedMessage() and
>> even getMessage(Locale) by delegating to the user code:
>>
>>   public class MathException {
>>
>>     public String getLocalizedMessage() {
>>       return ExceptionFactory.localize(Locale.getDefault(), this);
>>     }
>>
>>     public String getMessage(Locale locale) {
>>       return ExceptionFactory.localize(locale, this);
>>     }
>>
>>     ...
>>
>>   }
>>
>> One thing that would be nice would be that in addition to the get method,
>> MathException also provides a getKeys to retrieve all keys and a getType
>> to retrieve the type. The later correspond to the getPatern (or
>> getLocalizable)
>> I asked for a few years ago in ExceptionContext. The point for these
>> methods
>> is that if we provide users a way to retrieve the parameters that were
>> used
>> in the exception construction, then we can delegate localization to users
>> as they can do their own code that will rebuild a complete meaasage as
>> they
>> want. When you have only the keys and they have reused names like
>> OPERATOR
>> or VECTOR, it can't be delegated.
>
> If those are available (as suggested in Ole's example above), would you
> indeed
> be OK that localization is not a CM concern anymore?

Yes at the condition that user can use it to implement something like
the ExceptionLocalizer interface and this interface is already supported
by CM exceptions to implement getLocalizedMessage (at least). The
getLocalizedMessage is a standard method inherited directly from
Throwable, it is not an addition from us (on the other hand
getMessage(Locale) *is* an extension I promoted).

This getLocalizedMessage is the standard way many existing frameworks
use to display the message to end users, and we can't change this
behaviour to have them call the user localization code. So this user
localization code must lie somewhere beneath the standard
getLocalizedMessage call. The proposal above allow to divert it to
user code with CM providing only the required plumbing (but it must
still provide the plumbing).

>
> We could provide code of how to perform the translation in the userguide.

Yes.

>
>> Note that this is independent of the fact there is one or several
>> hierarchies.
>> If there are several ones, the two one-liners above must simply be copied
>> (yeah, code duplication, I know).
>>
>>>
>>>>>>>
>>>>>>>> I think it satisfies everyone's requirements with:
>>>>>>>> - A single MathException (No hierarchy)
>>>>>>> That would not satisfy everyone. :-!
>>>>>>>
>>>>>>>> - The ExceptionTypes Enum contains all the exception types
>>>>>>>> - The ExceptionTypes Enum 'key' maps to the corresponding
>>>>>>>> message 1 to 1
>>>>>>>> - The ExceptionFactory (Utility) throws exceptions, if necessary,
>>>>>>>> that have always have a single unique root cause, such as NPEs
>>>>>>> I was wondering whether the "factory" idea could indeed satisfy
>>>>>>> everyone.
>>>>>>> Rather than throwing the non-standard "MathException", the
>>>>>>> factory would
>>>>>>> generate one of the standard exceptions, constructed with the
>>>>>>> internal
>>>>>>> "MathException" as its cause:
>>>>>> I think it's good that CM throws CM specific exceptions.  This way
>>>>>> when I write the handler I can know that the exception is CM specific
>>>>>> without having to unwrap it.
>>>>> But if there are several CM exceptions hierarchies, the handler
>>>>> will have
>>>>> to check for every base type, leading to more code.
>>>> True dat - but if there are no CM exception hierarchies then they
>>>> don't :).
>>> I'd be interested in settling the matter of whether we must use a single
>>> hierarchy because of technical limitations, or if it is a good solution
>>> on its own, i.e. extending standard exceptions is not a better practice
>>> after all.
>>>
>>>>> We could provide a utility:
>>>>> public boolean isMathException(RuntimeException e) {
>>>>>   if (e instanceof MathException) {
>>>>>     return true;
>>>>>   }
>>>>>   final Throwable t = e.getCause();
>>>>>   if (t != null) {
>>>>>     if (e instanceof MathException) {
>>>>>       return true;
>>>>>     }
>>>>>   }
>>>>>   return false;
>>>>> }
>>>> Or just not wrap.
>>> Of course, but choosing one or the other is not a technical problem;
>>> it's design decision.  Do we have arguments (or reference to them)?
>>>
>>>>>>> public class ExceptionFactory {
>>>>>>> public static void throwIllegalArgumentException(MathException e) {
>>>>>>>     throw new IllegalArgumentException(e);
>>>>>>>   }
>>>>>>> public static void throwNullPointerException(MathException e) {
>>>>>>>     throw new NullPointerException(e);
>>>>>>>   }
>>>>>>> // And so on...
>>>>>>> }
>>>>>>> So, CM code would be
>>>>>>> public class Algo {
>>>>>>> public void evaluate(double value) {
>>>>>>>     // Check precondition.
>>>>>>>     final double min = computeMin();
>>>>>>>     if (value < min) {
>>>>>>>       final MathException e = new
>>>>>>> MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE,
>>>>>>> value);
>>>>>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>>>>>     }
>>>>>>> // Precondition OK.
>>>>>>>   }
>>>>>>> }
>>>>>> Another thing that I hinted to is that the the factory builds in the
>>>>>> precondition check in the throw method.  So that the line:
>>>>>> if (value < min) {
>>>>>> can be nixed.
>>>>> It seems nice to ensure that the exception raised is consistent
>>>>> with the
>>>>> checked condition.
>>>> That's the idea.
>>> OK, but do you foresee that all precondition checks will be handle by
>>> factory methods.
>>> It would not be so nice to have explicit checks sprinkled here and
>>> there.
>>>
>>>>> Then, a factory method like
>>>>>   throwNotStrictlyPositiveException(Number value, String key)
>>>>> should probably be renamed to
>>>>>   checkNotStrictlyPositiveException(Number value, String key)
>>>> 'check' is good.  I'm going to change it to check.
>>
>> as the name was changed to checkSomething, the last part Exception in
>> the name could be dropped.
>>
>>>>> Also, shouldn't the "key" argument should be optional?
>>>> The key is used to initialize the exception context with the Number
>>>> instance.  Different modules could have different keys.  For example
>>>> the Arithmetic module has keys X and Y.  So if Y caused the exception
>>>> then Y would be passed as the key.  So if we are checking both we
>>>> would do this:
>>>> checkNotStrictlyPositiveException(x, X);
>>>> checkNotStrictlyPositiveException(y, Y);
>>>>>
>>>>>>> Then, in an application's code:
>>>>>>> public void appMethod() {
>>>>>>>   // ...
>>>>>>> // Use CM.
>>>>>>>   try {
>>>>>>>     Algo a = new Algo();
>>>>>>>     a.evaluate(2);
>>>>>>>   } catch (IllegalArgumentException iae) {
>>>>>>>     final Throwable cause = iae.getCause();
>>>>>>>     if (cause instanceof MathException) {
>>>>>>>       final MathException e = (MathException) cause;
>>>>>>> // Rethrow an application-specific exception that will make more
>>>>>>> sense
>>>>>>>       // to my customers.
>>>>>>>       throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>>>>> e.get(VALUE));
>>>>>>>     }
>>>>>>>   }
>>>>>>> }
>>>>>>> This is all untested.
>>>>>>> Did I miss something?
>>
>> In the code above, if the iae does not have a cause, or if it is not
>> a MathException,
>> the iae should be rethrown.
>
> Indeed!
> The updated code (also unstested):
>
>    try {
>      Algo a = new Algo();
>      a.evaluate(2);
>    } catch (IllegalArgumentException iae) {
>      final MathException e = ExceptionFactory.getMathException(iae);
>
>      if (e != null) {
>        // Rethrow an application-specific exception that will make more
> sense
>        // to my customers.
>        throw new InvalidDataInputException(e.get(CONSTRAINT),
> e.get(VALUE));
>      } else {
>        throw iae;
>      }
>    }
>
>>>>>> I think you got it all...But the handler will be shorter if the
>>>>>> exception is not wrapped.
>>>>> But not significantly, I guess.
>>>>> We could also provide
>>>>> public MathException getMathException(RuntimeException e) {
>>>>>   if (e instanceof MathException) {
>>>>>     return (MathException) e;
>>>>>   }
>>>>>   final Throwable t = e.getCause();
>>>>>   if (t != null) {
>>>>>     if (e instanceof MathException) {
>>>>>       return (MathException) e;
>>>>>     }
>>>>>   }
>>>>>   return null;
>>>>> }
>>>>> And then define the other utility as:
>>>>> public boolean isMathException(RuntimeException e) {
>>>>>   return getMathException(e) != null;
>>>>> }
>>>>>
>>>>>> The pattern I'm used to is that libraries
>>>>>> wrap the exceptions of other libraries in order to offer a
>>>>>> standardized facade to the user.  For example Spring wraps Hibernate
>>>>>> exceptions, since Spring is a layer on top of Hibernate and other
>>>>>> data
>>>>>> access providers.
>>>>> What do they advertize?  Standard exception, possibly extended, or
>>>>> specific ones, possibly belonging to single hierarchy?
>>>> Spring namespaced - single hierarchy:
>>>>
>>>> http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/dao/DataAccessException.html
>>>>
>>>> BTW - this is blue sky thinking - but Spring Boot has an
>>>> @ExceptionHandler annotation that allows the developer to wire up an
>>>> exception handler.  It might be worth exploring something similar for
>>>> the purpose of automating I18N requirements.
>>>> @ExceptionHandler(MathException.class)
>>>> someClientCodeThatUsesCM();
>>>
>>> That would be quite necessary I'm afraid. ;-)
>>
>> Not necessarily. The above support for I18N is quite simple.
>
> Maybe too simple... ;-)
> [What did they say about global variables?]

If the static fields hurts your feelings, we can always hide
it using an official design pattern like the singleton for
ExceptionFactory, and even use the Initialization-on-demand
holder idiom to store the singleton. Then the localizer would
be an instance field and there would be a static getInstance()
method in the factory. Well, a singleton design pattern plus
a IODH idiom design pattern are really only a global variable
in a pretty dress, so it is only hiding the fact.

At the root, yes global variables are frowned upon, but they
do have some use for configuration and making sure some
configuration data can be retrieved from everywhere reliably.
There are many other places were global variables are used in
Java. Just to mention one example that is deirectly related
to our topic, Locale.getDefault() and Locale.setDefault() are
semantically really accesses to a global variable too.

best regards,
Luc

>
> Best regards,
> Gilles
>
>>
>> best regards,
>> Luc
>>
>>> Best regards,
>>> Gilles
>>>
>>>> Cheers,
>>>> Ole
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Gilles Sadowski
On Wed, 23 Dec 2015 20:18:10 +0100, Luc Maisonobe wrote:

> Le 23/12/2015 14:32, Gilles a écrit :
>> Hello.
>>
>> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>>> Le 2015-12-23 01:41, Gilles a écrit :
>>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>>>> Hi.
>>>>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>>>>> Hi,
>>>>>>>>> I was considering jumping into the JDKRandomGenerator
>>>>>>>>> exception
>>>>>>>>> discussion, but I did not want to hijack it.
>>>>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>>>>>
>>>>>>>> [...]
>>>>>>>> But I did not see how localization is handled.
>>>>>>> I did leave localization out.  I think localization was a hard
>>>>>>> requirement in earlier versions of CM, but I'm hoping that
>>>>>>> there is
>>>>>>> some flexibility on this
>>>>>> There was not, since I argued many times to leave it out.
>>>>>> So unless you can show practically how it can work, I have my
>>>>>> doubts
>>>>>> that we'll be allowed to go forward with this approach.
>>>>>>
>>>>>>> and that future versions can defer to a
>>>>>>> utility that uses the ExceptionTypes Enum instance as the key
>>>>>>> to look
>>>>>>> up the internationalized template string.
>>>>>> Looks good.  Where is the code? ;-)
>>>>> So CM clients would:
>>>>> catch(MathException e) {
>>>>>     String exceptionTemplate =
>>>>> ResourceBundle.getBundle("cm.exception.templates", new
>>>>> Locale("en",
>>>>> "US")).getString(e.getType());
>>>>>     String i18Nmessage = buildMessage(exceptionTemplate,
>>>>> e.getContext());
>>>>>     ...
>>>>> }
>>>>> I can prototype that out more.  Just trying to get a feel for how
>>>>> viable the concept is first.
>>>> I'm not sure I understand correctly.
>>>> Does that mean that
>>>> 1. Uncaught exceptions will lead to a message in English?
>>>> 2. Every "catch" must repeat the same calls (although the
>>>> arguments
>>>> are likely
>>>>    to be the same for all clauses (and for all applications)?
>>>> Comparing this with the current behaviour (where the translated
>>>> message String
>>>> is created when "e.getLocalizedMessage()" is called) is likely to
>>>> make people
>>>> unhappy.
>>>
>>> This could be made simpler with some task delegating between user
>>> code and CM code.
>>> What about :
>>>
>>>  interface ExceptionLocalizer {
>>>     /** Localize an exception message.
>>>       * @param locale locale to use
>>>       * @param me exception to localize
>>>       * @return localized message for the exception
>>>       */
>>>     String localize(Locale locale, MathException me);
>>>  }
>>>
>>> and having ExceptionFactory hold a user-provided implementation of
>>> this interface?
>>>
>>>  public class ExceptionFactory {
>>>
>>>    private static ExceptionLocalizer localizer = new
>>> NoOpLocalizer();
>>>
>>>    public static setLocalizer(ExceptionLocalizer l) {
>>>       localizer = l;
>>>    }
>>
>> I think that this is potentially dangerous for two reasons (if I'm
>> not mistaken): it's not thread-safe and it can be called by any
>> library used by the main application.
>
> Intermedaite libraries could also call it, and I hope they would be
> designed to use a consistent way for their own exception (they should
> let the user specify the localization mechanism, use it for
> themselves
> and pass the configuration to CM).

I'm not sure I follow.

IIUC the implications, libraries should be forbidden to call a method
such as "setLocalizer".

In fact "localizer" should be final. [It could be initialized in a way
similar to what is done by "slf4j".  But this is a lot of work not
worth
it if we can drop direct support for localiszation in CM.]

>
> Thread safety here is really not a concern (but we could protect it
> if desired). This setting is a configuration level setting, it is
> usually done once near the beginning of the main program. You don't
> change the mechanism every millisecond.
>
>>
>> I think that the "localizer" instance must be obtained in a way
>> which
>> the end-user controls.
>
> The user controls it. The setLocalizer method can be called directly
> by
> user, and in fact I expect the user to do it.

The user is not in control because any code he calls can override the
setting.

>>>
>>>    public static String localize(Locale locale, MathException me) {
>>>      return localizer.localize(locale, me);
>>>    }
>>>
>>>    /** Default implementation of the localizer that does nothing.
>>> */
>>>    private static class NoOpLocalizer implements ExceptionLocalizer
>>> {
>>>           /** {@inheritDoc} */
>>>           @Override
>>>           public String localize(MathException me) {
>>>            return me.getMessage();
>>>          }
>>>    }
>>>
>>>  }
>>>
>>> and MathException could implement both getLocalizedMessage() and
>>> even getMessage(Locale) by delegating to the user code:
>>>
>>>   public class MathException {
>>>
>>>     public String getLocalizedMessage() {
>>>       return ExceptionFactory.localize(Locale.getDefault(), this);
>>>     }
>>>
>>>     public String getMessage(Locale locale) {
>>>       return ExceptionFactory.localize(locale, this);
>>>     }
>>>
>>>     ...
>>>
>>>   }
>>>
>>> One thing that would be nice would be that in addition to the get
>>> method,
>>> MathException also provides a getKeys to retrieve all keys and a
>>> getType
>>> to retrieve the type. The later correspond to the getPatern (or
>>> getLocalizable)
>>> I asked for a few years ago in ExceptionContext. The point for
>>> these
>>> methods
>>> is that if we provide users a way to retrieve the parameters that
>>> were
>>> used
>>> in the exception construction, then we can delegate localization to
>>> users
>>> as they can do their own code that will rebuild a complete meaasage
>>> as
>>> they
>>> want. When you have only the keys and they have reused names like
>>> OPERATOR
>>> or VECTOR, it can't be delegated.
>>
>> If those are available (as suggested in Ole's example above), would
>> you
>> indeed
>> be OK that localization is not a CM concern anymore?
>
> Yes at the condition that user can use it to implement something like
> the ExceptionLocalizer interface and this interface is already
> supported
> by CM exceptions to implement getLocalizedMessage (at least). The
> getLocalizedMessage is a standard method inherited directly from
> Throwable, it is not an addition from us (on the other hand
> getMessage(Locale) *is* an extension I promoted).

I don't follow: I thought that if Ole's "MathException" provides
"getType",
"getKeys" and ("getValues" ?), then you have the same building blocks
to define a custom formatting (and localization).

By "dropping support", I mean dropping support. ;-)
I.e. no more "Localize..." classes under "org.apache.commons.math4"

The list of translated type could still be maintained here, in the same
way the unit tests and user guide are.

> This getLocalizedMessage is the standard way many existing frameworks
> use to display the message to end users, and we can't change this
> behaviour to have them call the user localization code. So this user
> localization code must lie somewhere beneath the standard
> getLocalizedMessage call. The proposal above allow to divert it to
> user code with CM providing only the required plumbing (but it must
> still provide the plumbing).
>
>>
>> We could provide code of how to perform the translation in the
>> userguide.
>
> Yes.
>
>>
>>> Note that this is independent of the fact there is one or several
>>> hierarchies.
>>> If there are several ones, the two one-liners above must simply be
>>> copied
>>> (yeah, code duplication, I know).
>>>
>>>>
>>>>>>>>
>>>>>>>>> I think it satisfies everyone's requirements with:
>>>>>>>>> - A single MathException (No hierarchy)
>>>>>>>> That would not satisfy everyone. :-!
>>>>>>>>
>>>>>>>>> - The ExceptionTypes Enum contains all the exception types
>>>>>>>>> - The ExceptionTypes Enum 'key' maps to the corresponding
>>>>>>>>> message 1 to 1
>>>>>>>>> - The ExceptionFactory (Utility) throws exceptions, if
>>>>>>>>> necessary,
>>>>>>>>> that have always have a single unique root cause, such as
>>>>>>>>> NPEs
>>>>>>>> I was wondering whether the "factory" idea could indeed
>>>>>>>> satisfy
>>>>>>>> everyone.
>>>>>>>> Rather than throwing the non-standard "MathException", the
>>>>>>>> factory would
>>>>>>>> generate one of the standard exceptions, constructed with the
>>>>>>>> internal
>>>>>>>> "MathException" as its cause:
>>>>>>> I think it's good that CM throws CM specific exceptions.  This
>>>>>>> way
>>>>>>> when I write the handler I can know that the exception is CM
>>>>>>> specific
>>>>>>> without having to unwrap it.
>>>>>> But if there are several CM exceptions hierarchies, the handler
>>>>>> will have
>>>>>> to check for every base type, leading to more code.
>>>>> True dat - but if there are no CM exception hierarchies then they
>>>>> don't :).
>>>> I'd be interested in settling the matter of whether we must use a
>>>> single
>>>> hierarchy because of technical limitations, or if it is a good
>>>> solution
>>>> on its own, i.e. extending standard exceptions is not a better
>>>> practice
>>>> after all.
>>>>
>>>>>> We could provide a utility:
>>>>>> public boolean isMathException(RuntimeException e) {
>>>>>>   if (e instanceof MathException) {
>>>>>>     return true;
>>>>>>   }
>>>>>>   final Throwable t = e.getCause();
>>>>>>   if (t != null) {
>>>>>>     if (e instanceof MathException) {
>>>>>>       return true;
>>>>>>     }
>>>>>>   }
>>>>>>   return false;
>>>>>> }
>>>>> Or just not wrap.
>>>> Of course, but choosing one or the other is not a technical
>>>> problem;
>>>> it's design decision.  Do we have arguments (or reference to
>>>> them)?
>>>>
>>>>>>>> public class ExceptionFactory {
>>>>>>>> public static void throwIllegalArgumentException(MathException
>>>>>>>> e) {
>>>>>>>>     throw new IllegalArgumentException(e);
>>>>>>>>   }
>>>>>>>> public static void throwNullPointerException(MathException e)
>>>>>>>> {
>>>>>>>>     throw new NullPointerException(e);
>>>>>>>>   }
>>>>>>>> // And so on...
>>>>>>>> }
>>>>>>>> So, CM code would be
>>>>>>>> public class Algo {
>>>>>>>> public void evaluate(double value) {
>>>>>>>>     // Check precondition.
>>>>>>>>     final double min = computeMin();
>>>>>>>>     if (value < min) {
>>>>>>>>       final MathException e = new
>>>>>>>> MathException(NUMBER_TOO_SMALL).put(CONSTRAINT,
>>>>>>>> min).put(VALUE,
>>>>>>>> value);
>>>>>>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>>>>>>     }
>>>>>>>> // Precondition OK.
>>>>>>>>   }
>>>>>>>> }
>>>>>>> Another thing that I hinted to is that the the factory builds
>>>>>>> in the
>>>>>>> precondition check in the throw method.  So that the line:
>>>>>>> if (value < min) {
>>>>>>> can be nixed.
>>>>>> It seems nice to ensure that the exception raised is consistent
>>>>>> with the
>>>>>> checked condition.
>>>>> That's the idea.
>>>> OK, but do you foresee that all precondition checks will be handle
>>>> by
>>>> factory methods.
>>>> It would not be so nice to have explicit checks sprinkled here and
>>>> there.
>>>>
>>>>>> Then, a factory method like
>>>>>>   throwNotStrictlyPositiveException(Number value, String key)
>>>>>> should probably be renamed to
>>>>>>   checkNotStrictlyPositiveException(Number value, String key)
>>>>> 'check' is good.  I'm going to change it to check.
>>>
>>> as the name was changed to checkSomething, the last part Exception
>>> in
>>> the name could be dropped.
>>>
>>>>>> Also, shouldn't the "key" argument should be optional?
>>>>> The key is used to initialize the exception context with the
>>>>> Number
>>>>> instance.  Different modules could have different keys.  For
>>>>> example
>>>>> the Arithmetic module has keys X and Y.  So if Y caused the
>>>>> exception
>>>>> then Y would be passed as the key.  So if we are checking both we
>>>>> would do this:
>>>>> checkNotStrictlyPositiveException(x, X);
>>>>> checkNotStrictlyPositiveException(y, Y);
>>>>>>
>>>>>>>> Then, in an application's code:
>>>>>>>> public void appMethod() {
>>>>>>>>   // ...
>>>>>>>> // Use CM.
>>>>>>>>   try {
>>>>>>>>     Algo a = new Algo();
>>>>>>>>     a.evaluate(2);
>>>>>>>>   } catch (IllegalArgumentException iae) {
>>>>>>>>     final Throwable cause = iae.getCause();
>>>>>>>>     if (cause instanceof MathException) {
>>>>>>>>       final MathException e = (MathException) cause;
>>>>>>>> // Rethrow an application-specific exception that will make
>>>>>>>> more
>>>>>>>> sense
>>>>>>>>       // to my customers.
>>>>>>>>       throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>>>>>> e.get(VALUE));
>>>>>>>>     }
>>>>>>>>   }
>>>>>>>> }
>>>>>>>> This is all untested.
>>>>>>>> Did I miss something?
>>>
>>> In the code above, if the iae does not have a cause, or if it is
>>> not
>>> a MathException,
>>> the iae should be rethrown.
>>
>> Indeed!
>> The updated code (also unstested):
>>
>>    try {
>>      Algo a = new Algo();
>>      a.evaluate(2);
>>    } catch (IllegalArgumentException iae) {
>>      final MathException e = ExceptionFactory.getMathException(iae);
>>
>>      if (e != null) {
>>        // Rethrow an application-specific exception that will make
>> more
>> sense
>>        // to my customers.
>>        throw new InvalidDataInputException(e.get(CONSTRAINT),
>> e.get(VALUE));
>>      } else {
>>        throw iae;
>>      }
>>    }
>>
>>>>>>> I think you got it all...But the handler will be shorter if the
>>>>>>> exception is not wrapped.
>>>>>> But not significantly, I guess.
>>>>>> We could also provide
>>>>>> public MathException getMathException(RuntimeException e) {
>>>>>>   if (e instanceof MathException) {
>>>>>>     return (MathException) e;
>>>>>>   }
>>>>>>   final Throwable t = e.getCause();
>>>>>>   if (t != null) {
>>>>>>     if (e instanceof MathException) {
>>>>>>       return (MathException) e;
>>>>>>     }
>>>>>>   }
>>>>>>   return null;
>>>>>> }
>>>>>> And then define the other utility as:
>>>>>> public boolean isMathException(RuntimeException e) {
>>>>>>   return getMathException(e) != null;
>>>>>> }
>>>>>>
>>>>>>> The pattern I'm used to is that libraries
>>>>>>> wrap the exceptions of other libraries in order to offer a
>>>>>>> standardized facade to the user.  For example Spring wraps
>>>>>>> Hibernate
>>>>>>> exceptions, since Spring is a layer on top of Hibernate and
>>>>>>> other
>>>>>>> data
>>>>>>> access providers.
>>>>>> What do they advertize?  Standard exception, possibly extended,
>>>>>> or
>>>>>> specific ones, possibly belonging to single hierarchy?
>>>>> Spring namespaced - single hierarchy:
>>>>>
>>>>>
>>>>> http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/dao/DataAccessException.html
>>>>>
>>>>> BTW - this is blue sky thinking - but Spring Boot has an
>>>>> @ExceptionHandler annotation that allows the developer to wire up
>>>>> an
>>>>> exception handler.  It might be worth exploring something similar
>>>>> for
>>>>> the purpose of automating I18N requirements.
>>>>> @ExceptionHandler(MathException.class)
>>>>> someClientCodeThatUsesCM();
>>>>
>>>> That would be quite necessary I'm afraid. ;-)
>>>
>>> Not necessarily. The above support for I18N is quite simple.
>>
>> Maybe too simple... ;-)
>> [What did they say about global variables?]
>
> If the static fields hurts your feelings,

It's not just that.

> we can always hide
> it using an official design pattern like the singleton for
> ExceptionFactory, and even use the Initialization-on-demand
> holder idiom to store the singleton. Then the localizer would
> be an instance field and there would be a static getInstance()
> method in the factory. Well, a singleton design pattern plus
> a IODH idiom design pattern are really only a global variable
> in a pretty dress, so it is only hiding the fact.

Unless I'm mistaken, other singletons in CM are initialized by CM,
and cannot be changed afterwards.

> At the root, yes global variables are frowned upon, but they
> do have some use for configuration and making sure some
> configuration data can be retrieved from everywhere reliably.
> There are many other places were global variables are used in
> Java. Just to mention one example that is deirectly related
> to our topic, Locale.getDefault() and Locale.setDefault() are
> semantically really accesses to a global variable too.

I think that this is not something to introduce lightly.
When/if we'll want to explore multi-threading, it will add to
the problems.
If the localization feature can be achieved without resorting
to a global setting, we should favour it.

Best,
Gilles

>
> best regards,
> Luc
>
>>
>> Best regards,
>> Gilles
>>
>>>
>>> best regards,
>>> Luc
>>>
>>>> Best regards,
>>>> Gilles
>>>>
>>>>> Cheers,
>>>>> Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Luc Maisonobe-2
Le 24/12/2015 01:41, Gilles a écrit :

> On Wed, 23 Dec 2015 20:18:10 +0100, Luc Maisonobe wrote:
>> Le 23/12/2015 14:32, Gilles a écrit :
>>> Hello.
>>>
>>> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>>>> Le 2015-12-23 01:41, Gilles a écrit :
>>>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>>>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>>>>> Hi.
>>>>>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>>>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> I was considering jumping into the JDKRandomGenerator exception
>>>>>>>>>> discussion, but I did not want to hijack it.
>>>>>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>> But I did not see how localization is handled.
>>>>>>>> I did leave localization out.  I think localization was a hard
>>>>>>>> requirement in earlier versions of CM, but I'm hoping that there is
>>>>>>>> some flexibility on this
>>>>>>> There was not, since I argued many times to leave it out.
>>>>>>> So unless you can show practically how it can work, I have my doubts
>>>>>>> that we'll be allowed to go forward with this approach.
>>>>>>>
>>>>>>>> and that future versions can defer to a
>>>>>>>> utility that uses the ExceptionTypes Enum instance as the key to
>>>>>>>> look
>>>>>>>> up the internationalized template string.
>>>>>>> Looks good.  Where is the code? ;-)
>>>>>> So CM clients would:
>>>>>> catch(MathException e) {
>>>>>>     String exceptionTemplate =
>>>>>> ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
>>>>>> "US")).getString(e.getType());
>>>>>>     String i18Nmessage = buildMessage(exceptionTemplate,
>>>>>> e.getContext());
>>>>>>     ...
>>>>>> }
>>>>>> I can prototype that out more.  Just trying to get a feel for how
>>>>>> viable the concept is first.
>>>>> I'm not sure I understand correctly.
>>>>> Does that mean that
>>>>> 1. Uncaught exceptions will lead to a message in English?
>>>>> 2. Every "catch" must repeat the same calls (although the arguments
>>>>> are likely
>>>>>    to be the same for all clauses (and for all applications)?
>>>>> Comparing this with the current behaviour (where the translated
>>>>> message String
>>>>> is created when "e.getLocalizedMessage()" is called) is likely to
>>>>> make people
>>>>> unhappy.
>>>>
>>>> This could be made simpler with some task delegating between user
>>>> code and CM code.
>>>> What about :
>>>>
>>>>  interface ExceptionLocalizer {
>>>>     /** Localize an exception message.
>>>>       * @param locale locale to use
>>>>       * @param me exception to localize
>>>>       * @return localized message for the exception
>>>>       */
>>>>     String localize(Locale locale, MathException me);
>>>>  }
>>>>
>>>> and having ExceptionFactory hold a user-provided implementation of
>>>> this interface?
>>>>
>>>>  public class ExceptionFactory {
>>>>
>>>>    private static ExceptionLocalizer localizer = new NoOpLocalizer();
>>>>
>>>>    public static setLocalizer(ExceptionLocalizer l) {
>>>>       localizer = l;
>>>>    }
>>>
>>> I think that this is potentially dangerous for two reasons (if I'm
>>> not mistaken): it's not thread-safe and it can be called by any
>>> library used by the main application.
>>
>> Intermedaite libraries could also call it, and I hope they would be
>> designed to use a consistent way for their own exception (they should
>> let the user specify the localization mechanism, use it for themselves
>> and pass the configuration to CM).
>
> I'm not sure I follow.
>
> IIUC the implications, libraries should be forbidden to call a method
> such as "setLocalizer".

It's a design choice for the upper libraries, not for CM.

>
> In fact "localizer" should be final. [It could be initialized in a way
> similar to what is done by "slf4j".  But this is a lot of work not worth
> it if we can drop direct support for localiszation in CM.]

This would be over-engineering IMHO. From a theoretical point of view,
yes it would be cleaner, but this is really nitpicking. Documenting
proper use case seems sufficient.

>
>>
>> Thread safety here is really not a concern (but we could protect it
>> if desired). This setting is a configuration level setting, it is
>> usually done once near the beginning of the main program. You don't
>> change the mechanism every millisecond.
>>
>>>
>>> I think that the "localizer" instance must be obtained in a way which
>>> the end-user controls.
>>
>> The user controls it. The setLocalizer method can be called directly by
>> user, and in fact I expect the user to do it.
>
> The user is not in control because any code he calls can override the
> setting.
>
>>>>
>>>>    public static String localize(Locale locale, MathException me) {
>>>>      return localizer.localize(locale, me);
>>>>    }
>>>>
>>>>    /** Default implementation of the localizer that does nothing. */
>>>>    private static class NoOpLocalizer implements ExceptionLocalizer {
>>>>           /** {@inheritDoc} */
>>>>           @Override
>>>>           public String localize(MathException me) {
>>>>            return me.getMessage();
>>>>          }
>>>>    }
>>>>
>>>>  }
>>>>
>>>> and MathException could implement both getLocalizedMessage() and
>>>> even getMessage(Locale) by delegating to the user code:
>>>>
>>>>   public class MathException {
>>>>
>>>>     public String getLocalizedMessage() {
>>>>       return ExceptionFactory.localize(Locale.getDefault(), this);
>>>>     }
>>>>
>>>>     public String getMessage(Locale locale) {
>>>>       return ExceptionFactory.localize(locale, this);
>>>>     }
>>>>
>>>>     ...
>>>>
>>>>   }
>>>>
>>>> One thing that would be nice would be that in addition to the get
>>>> method,
>>>> MathException also provides a getKeys to retrieve all keys and a
>>>> getType
>>>> to retrieve the type. The later correspond to the getPatern (or
>>>> getLocalizable)
>>>> I asked for a few years ago in ExceptionContext. The point for these
>>>> methods
>>>> is that if we provide users a way to retrieve the parameters that were
>>>> used
>>>> in the exception construction, then we can delegate localization to
>>>> users
>>>> as they can do their own code that will rebuild a complete meaasage as
>>>> they
>>>> want. When you have only the keys and they have reused names like
>>>> OPERATOR
>>>> or VECTOR, it can't be delegated.
>>>
>>> If those are available (as suggested in Ole's example above), would you
>>> indeed
>>> be OK that localization is not a CM concern anymore?
>>
>> Yes at the condition that user can use it to implement something like
>> the ExceptionLocalizer interface and this interface is already supported
>> by CM exceptions to implement getLocalizedMessage (at least). The
>> getLocalizedMessage is a standard method inherited directly from
>> Throwable, it is not an addition from us (on the other hand
>> getMessage(Locale) *is* an extension I promoted).
>
> I don't follow: I thought that if Ole's "MathException" provides "getType",
> "getKeys" and ("getValues" ?), then you have the same building blocks
> to define a custom formatting (and localization).

Yes, and this is what is used at user level to implement ExceptionLocalizer.

>
> By "dropping support", I mean dropping support. ;-)
> I.e. no more "Localize..." classes under "org.apache.commons.math4"

Then -1.

When our users build a large application, they rely on numerous
different libraries and tools, both open-source and proprietary.
These libraries do have standard interfaces so they can be used
together. The Java standard library is one of them. the
getLocalizedMessage method is specified there. Many of the libraries
and tolls user will assemble rely on it. Deciding that for the sake
of Apache Commons Math we do not abide to this and decide that all
other existing code should adapt to a different design is a clear
no go for me.

Look at it, it is *only* one field with its setter and two one line
methods defined in the top level MathException class in order to
abide to a standardized interface widely used.


>
> The list of translated type could still be maintained here, in the same
> way the unit tests and user guide are.

I'm not sure. If we decide to delegate the localization to the user
and simply provide the two one-liners hook to call it, then we can
remove the list of translated types and let the user handle it. It
would also allow them to support additional languages. For now,
we support only one, we could drop it using this delegation mechanism.

>
>> This getLocalizedMessage is the standard way many existing frameworks
>> use to display the message to end users, and we can't change this
>> behaviour to have them call the user localization code. So this user
>> localization code must lie somewhere beneath the standard
>> getLocalizedMessage call. The proposal above allow to divert it to
>> user code with CM providing only the required plumbing (but it must
>> still provide the plumbing).
>>
>>>
>>> We could provide code of how to perform the translation in the
>>> userguide.
>>
>> Yes.
>>
>>>
>>>> Note that this is independent of the fact there is one or several
>>>> hierarchies.
>>>> If there are several ones, the two one-liners above must simply be
>>>> copied
>>>> (yeah, code duplication, I know).
>>>>
>>>>>
>>>>>>>>>
>>>>>>>>>> I think it satisfies everyone's requirements with:
>>>>>>>>>> - A single MathException (No hierarchy)
>>>>>>>>> That would not satisfy everyone. :-!
>>>>>>>>>
>>>>>>>>>> - The ExceptionTypes Enum contains all the exception types
>>>>>>>>>> - The ExceptionTypes Enum 'key' maps to the corresponding
>>>>>>>>>> message 1 to 1
>>>>>>>>>> - The ExceptionFactory (Utility) throws exceptions, if necessary,
>>>>>>>>>> that have always have a single unique root cause, such as NPEs
>>>>>>>>> I was wondering whether the "factory" idea could indeed satisfy
>>>>>>>>> everyone.
>>>>>>>>> Rather than throwing the non-standard "MathException", the
>>>>>>>>> factory would
>>>>>>>>> generate one of the standard exceptions, constructed with the
>>>>>>>>> internal
>>>>>>>>> "MathException" as its cause:
>>>>>>>> I think it's good that CM throws CM specific exceptions.  This way
>>>>>>>> when I write the handler I can know that the exception is CM
>>>>>>>> specific
>>>>>>>> without having to unwrap it.
>>>>>>> But if there are several CM exceptions hierarchies, the handler
>>>>>>> will have
>>>>>>> to check for every base type, leading to more code.
>>>>>> True dat - but if there are no CM exception hierarchies then they
>>>>>> don't :).
>>>>> I'd be interested in settling the matter of whether we must use a
>>>>> single
>>>>> hierarchy because of technical limitations, or if it is a good
>>>>> solution
>>>>> on its own, i.e. extending standard exceptions is not a better
>>>>> practice
>>>>> after all.
>>>>>
>>>>>>> We could provide a utility:
>>>>>>> public boolean isMathException(RuntimeException e) {
>>>>>>>   if (e instanceof MathException) {
>>>>>>>     return true;
>>>>>>>   }
>>>>>>>   final Throwable t = e.getCause();
>>>>>>>   if (t != null) {
>>>>>>>     if (e instanceof MathException) {
>>>>>>>       return true;
>>>>>>>     }
>>>>>>>   }
>>>>>>>   return false;
>>>>>>> }
>>>>>> Or just not wrap.
>>>>> Of course, but choosing one or the other is not a technical problem;
>>>>> it's design decision.  Do we have arguments (or reference to them)?
>>>>>
>>>>>>>>> public class ExceptionFactory {
>>>>>>>>> public static void throwIllegalArgumentException(MathException
>>>>>>>>> e) {
>>>>>>>>>     throw new IllegalArgumentException(e);
>>>>>>>>>   }
>>>>>>>>> public static void throwNullPointerException(MathException e) {
>>>>>>>>>     throw new NullPointerException(e);
>>>>>>>>>   }
>>>>>>>>> // And so on...
>>>>>>>>> }
>>>>>>>>> So, CM code would be
>>>>>>>>> public class Algo {
>>>>>>>>> public void evaluate(double value) {
>>>>>>>>>     // Check precondition.
>>>>>>>>>     final double min = computeMin();
>>>>>>>>>     if (value < min) {
>>>>>>>>>       final MathException e = new
>>>>>>>>> MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE,
>>>>>>>>> value);
>>>>>>>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>>>>>>>     }
>>>>>>>>> // Precondition OK.
>>>>>>>>>   }
>>>>>>>>> }
>>>>>>>> Another thing that I hinted to is that the the factory builds in
>>>>>>>> the
>>>>>>>> precondition check in the throw method.  So that the line:
>>>>>>>> if (value < min) {
>>>>>>>> can be nixed.
>>>>>>> It seems nice to ensure that the exception raised is consistent
>>>>>>> with the
>>>>>>> checked condition.
>>>>>> That's the idea.
>>>>> OK, but do you foresee that all precondition checks will be handle by
>>>>> factory methods.
>>>>> It would not be so nice to have explicit checks sprinkled here and
>>>>> there.
>>>>>
>>>>>>> Then, a factory method like
>>>>>>>   throwNotStrictlyPositiveException(Number value, String key)
>>>>>>> should probably be renamed to
>>>>>>>   checkNotStrictlyPositiveException(Number value, String key)
>>>>>> 'check' is good.  I'm going to change it to check.
>>>>
>>>> as the name was changed to checkSomething, the last part Exception in
>>>> the name could be dropped.
>>>>
>>>>>>> Also, shouldn't the "key" argument should be optional?
>>>>>> The key is used to initialize the exception context with the Number
>>>>>> instance.  Different modules could have different keys.  For example
>>>>>> the Arithmetic module has keys X and Y.  So if Y caused the exception
>>>>>> then Y would be passed as the key.  So if we are checking both we
>>>>>> would do this:
>>>>>> checkNotStrictlyPositiveException(x, X);
>>>>>> checkNotStrictlyPositiveException(y, Y);
>>>>>>>
>>>>>>>>> Then, in an application's code:
>>>>>>>>> public void appMethod() {
>>>>>>>>>   // ...
>>>>>>>>> // Use CM.
>>>>>>>>>   try {
>>>>>>>>>     Algo a = new Algo();
>>>>>>>>>     a.evaluate(2);
>>>>>>>>>   } catch (IllegalArgumentException iae) {
>>>>>>>>>     final Throwable cause = iae.getCause();
>>>>>>>>>     if (cause instanceof MathException) {
>>>>>>>>>       final MathException e = (MathException) cause;
>>>>>>>>> // Rethrow an application-specific exception that will make more
>>>>>>>>> sense
>>>>>>>>>       // to my customers.
>>>>>>>>>       throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>>>>>>> e.get(VALUE));
>>>>>>>>>     }
>>>>>>>>>   }
>>>>>>>>> }
>>>>>>>>> This is all untested.
>>>>>>>>> Did I miss something?
>>>>
>>>> In the code above, if the iae does not have a cause, or if it is not
>>>> a MathException,
>>>> the iae should be rethrown.
>>>
>>> Indeed!
>>> The updated code (also unstested):
>>>
>>>    try {
>>>      Algo a = new Algo();
>>>      a.evaluate(2);
>>>    } catch (IllegalArgumentException iae) {
>>>      final MathException e = ExceptionFactory.getMathException(iae);
>>>
>>>      if (e != null) {
>>>        // Rethrow an application-specific exception that will make more
>>> sense
>>>        // to my customers.
>>>        throw new InvalidDataInputException(e.get(CONSTRAINT),
>>> e.get(VALUE));
>>>      } else {
>>>        throw iae;
>>>      }
>>>    }
>>>
>>>>>>>> I think you got it all...But the handler will be shorter if the
>>>>>>>> exception is not wrapped.
>>>>>>> But not significantly, I guess.
>>>>>>> We could also provide
>>>>>>> public MathException getMathException(RuntimeException e) {
>>>>>>>   if (e instanceof MathException) {
>>>>>>>     return (MathException) e;
>>>>>>>   }
>>>>>>>   final Throwable t = e.getCause();
>>>>>>>   if (t != null) {
>>>>>>>     if (e instanceof MathException) {
>>>>>>>       return (MathException) e;
>>>>>>>     }
>>>>>>>   }
>>>>>>>   return null;
>>>>>>> }
>>>>>>> And then define the other utility as:
>>>>>>> public boolean isMathException(RuntimeException e) {
>>>>>>>   return getMathException(e) != null;
>>>>>>> }
>>>>>>>
>>>>>>>> The pattern I'm used to is that libraries
>>>>>>>> wrap the exceptions of other libraries in order to offer a
>>>>>>>> standardized facade to the user.  For example Spring wraps
>>>>>>>> Hibernate
>>>>>>>> exceptions, since Spring is a layer on top of Hibernate and other
>>>>>>>> data
>>>>>>>> access providers.
>>>>>>> What do they advertize?  Standard exception, possibly extended, or
>>>>>>> specific ones, possibly belonging to single hierarchy?
>>>>>> Spring namespaced - single hierarchy:
>>>>>>
>>>>>>
>>>>>> http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/dao/DataAccessException.html
>>>>>>
>>>>>>
>>>>>> BTW - this is blue sky thinking - but Spring Boot has an
>>>>>> @ExceptionHandler annotation that allows the developer to wire up an
>>>>>> exception handler.  It might be worth exploring something similar for
>>>>>> the purpose of automating I18N requirements.
>>>>>> @ExceptionHandler(MathException.class)
>>>>>> someClientCodeThatUsesCM();
>>>>>
>>>>> That would be quite necessary I'm afraid. ;-)
>>>>
>>>> Not necessarily. The above support for I18N is quite simple.
>>>
>>> Maybe too simple... ;-)
>>> [What did they say about global variables?]
>>
>> If the static fields hurts your feelings,
>
> It's not just that.
>
>> we can always hide
>> it using an official design pattern like the singleton for
>> ExceptionFactory, and even use the Initialization-on-demand
>> holder idiom to store the singleton. Then the localizer would
>> be an instance field and there would be a static getInstance()
>> method in the factory. Well, a singleton design pattern plus
>> a IODH idiom design pattern are really only a global variable
>> in a pretty dress, so it is only hiding the fact.
>
> Unless I'm mistaken, other singletons in CM are initialized by CM,
> and cannot be changed afterwards.
>
>> At the root, yes global variables are frowned upon, but they
>> do have some use for configuration and making sure some
>> configuration data can be retrieved from everywhere reliably.
>> There are many other places were global variables are used in
>> Java. Just to mention one example that is deirectly related
>> to our topic, Locale.getDefault() and Locale.setDefault() are
>> semantically really accesses to a global variable too.
>
> I think that this is not something to introduce lightly.
> When/if we'll want to explore multi-threading, it will add to
> the problems.

I don't agree at all with this statement.

This is a configuration setting, expected to be called once
at start time! I cannot see any case with users attempting
to do it hundreds of time per seconds with different localizers
to handle localization. This can be documented and users can be
warned against.

What I do expect is, in cases of server applications, having
a server answering to remote requests using different languages.
This is what the new getMessage(Locale) is designed for. Here,
the locale changes, not the mechanism to support it, and it
is not a global variable, just a method argument. It is already
safe in multi-threaded environments.

The setLocalizer method is not a computation algorithm expected
to be called millions of times and that therefore could experience
clashes in case of concurrency.

best regards,
Luc

> If the localization feature can be achieved without resorting
> to a global setting, we should favour it.
>
> Best,
> Gilles
>
>>
>> best regards,
>> Luc
>>
>>>
>>> Best regards,
>>> Gilles
>>>
>>>>
>>>> best regards,
>>>> Luc
>>>>
>>>>> Best regards,
>>>>> Gilles
>>>>>
>>>>>> Cheers,
>>>>>> Ole
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Gilles Sadowski
On Thu, 24 Dec 2015 09:36:34 +0100, Luc Maisonobe wrote:

> Le 24/12/2015 01:41, Gilles a écrit :
>> On Wed, 23 Dec 2015 20:18:10 +0100, Luc Maisonobe wrote:
>>> Le 23/12/2015 14:32, Gilles a écrit :
>>>> Hello.
>>>>
>>>> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>>>>> Le 2015-12-23 01:41, Gilles a écrit :
>>>>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>>>>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>>>>>> Hi.
>>>>>>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>>>>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>>>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> I was considering jumping into the JDKRandomGenerator
>>>>>>>>>>> exception
>>>>>>>>>>> discussion, but I did not want to hijack it.
>>>>>>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> [...]
>>>>>>>>>> But I did not see how localization is handled.
>>>>>>>>> I did leave localization out.  I think localization was a
>>>>>>>>> hard
>>>>>>>>> requirement in earlier versions of CM, but I'm hoping that
>>>>>>>>> there is
>>>>>>>>> some flexibility on this
>>>>>>>> There was not, since I argued many times to leave it out.
>>>>>>>> So unless you can show practically how it can work, I have my
>>>>>>>> doubts
>>>>>>>> that we'll be allowed to go forward with this approach.
>>>>>>>>
>>>>>>>>> and that future versions can defer to a
>>>>>>>>> utility that uses the ExceptionTypes Enum instance as the key
>>>>>>>>> to
>>>>>>>>> look
>>>>>>>>> up the internationalized template string.
>>>>>>>> Looks good.  Where is the code? ;-)
>>>>>>> So CM clients would:
>>>>>>> catch(MathException e) {
>>>>>>>     String exceptionTemplate =
>>>>>>> ResourceBundle.getBundle("cm.exception.templates", new
>>>>>>> Locale("en",
>>>>>>> "US")).getString(e.getType());
>>>>>>>     String i18Nmessage = buildMessage(exceptionTemplate,
>>>>>>> e.getContext());
>>>>>>>     ...
>>>>>>> }
>>>>>>> I can prototype that out more.  Just trying to get a feel for
>>>>>>> how
>>>>>>> viable the concept is first.
>>>>>> I'm not sure I understand correctly.
>>>>>> Does that mean that
>>>>>> 1. Uncaught exceptions will lead to a message in English?
>>>>>> 2. Every "catch" must repeat the same calls (although the
>>>>>> arguments
>>>>>> are likely
>>>>>>    to be the same for all clauses (and for all applications)?
>>>>>> Comparing this with the current behaviour (where the translated
>>>>>> message String
>>>>>> is created when "e.getLocalizedMessage()" is called) is likely
>>>>>> to
>>>>>> make people
>>>>>> unhappy.
>>>>>
>>>>> This could be made simpler with some task delegating between user
>>>>> code and CM code.
>>>>> What about :
>>>>>
>>>>>  interface ExceptionLocalizer {
>>>>>     /** Localize an exception message.
>>>>>       * @param locale locale to use
>>>>>       * @param me exception to localize
>>>>>       * @return localized message for the exception
>>>>>       */
>>>>>     String localize(Locale locale, MathException me);
>>>>>  }
>>>>>
>>>>> and having ExceptionFactory hold a user-provided implementation
>>>>> of
>>>>> this interface?
>>>>>
>>>>>  public class ExceptionFactory {
>>>>>
>>>>>    private static ExceptionLocalizer localizer = new
>>>>> NoOpLocalizer();
>>>>>
>>>>>    public static setLocalizer(ExceptionLocalizer l) {
>>>>>       localizer = l;
>>>>>    }
>>>>
>>>> I think that this is potentially dangerous for two reasons (if I'm
>>>> not mistaken): it's not thread-safe and it can be called by any
>>>> library used by the main application.
>>>
>>> Intermedaite libraries could also call it, and I hope they would be
>>> designed to use a consistent way for their own exception (they
>>> should
>>> let the user specify the localization mechanism, use it for
>>> themselves
>>> and pass the configuration to CM).
>>
>> I'm not sure I follow.
>>
>> IIUC the implications, libraries should be forbidden to call a
>> method
>> such as "setLocalizer".
>
> It's a design choice for the upper libraries, not for CM.

Not for upper libraries, only for the user!

Anyway, the design choice at CM level is: localization or not?

My opinion is that a low-level component should not do localization.

If the exception is a programming error, it is a bug (bad input
provided by the caller).
When something like that is encountered, the stack trace must be
reported to the caller of the method that triggered the exception
(either application developer, or CM developer).
I'm sure that a localized detailed message is a nuisance to the
people who have to debug (what if we provided e.g. Chinese
translations?).

If people feel that an operator cannot see a CM message in English
on his console, what do they do to prevent the JVM to show them?

For the few cases in CM that cannot be safe-guarded by precondition
checks, it's less clear-cut.
But I still think that localization is a job for a wrapper.
I.e. if CM would throw an exception instance whose type is a one-to-one
mapping to a cause, the wrapper has all the info to make a full report
(in any language).

>>>
>>> Thread safety here is really not a concern (but we could protect it
>>> if desired). This setting is a configuration level setting, it is
>>> usually done once near the beginning of the main program. You don't
>>> change the mechanism every millisecond.
>>>
>>>>
>>>> I think that the "localizer" instance must be obtained in a way
>>>> which
>>>> the end-user controls.
>>>
>>> The user controls it. The setLocalizer method can be called
>>> directly by
>>> user, and in fact I expect the user to do it.
>>
>> The user is not in control because any code he calls can override
>> the
>> setting.
>>
>>>>>
>>>>>    public static String localize(Locale locale, MathException me)
>>>>> {
>>>>>      return localizer.localize(locale, me);
>>>>>    }
>>>>>
>>>>>    /** Default implementation of the localizer that does nothing.
>>>>> */
>>>>>    private static class NoOpLocalizer implements
>>>>> ExceptionLocalizer {
>>>>>           /** {@inheritDoc} */
>>>>>           @Override
>>>>>           public String localize(MathException me) {
>>>>>            return me.getMessage();
>>>>>          }
>>>>>    }
>>>>>
>>>>>  }
>>>>>
>>>>> and MathException could implement both getLocalizedMessage() and
>>>>> even getMessage(Locale) by delegating to the user code:
>>>>>
>>>>>   public class MathException {
>>>>>
>>>>>     public String getLocalizedMessage() {
>>>>>       return ExceptionFactory.localize(Locale.getDefault(),
>>>>> this);
>>>>>     }
>>>>>
>>>>>     public String getMessage(Locale locale) {
>>>>>       return ExceptionFactory.localize(locale, this);
>>>>>     }
>>>>>
>>>>>     ...
>>>>>
>>>>>   }
>>>>>
>>>>> One thing that would be nice would be that in addition to the get
>>>>> method,
>>>>> MathException also provides a getKeys to retrieve all keys and a
>>>>> getType
>>>>> to retrieve the type. The later correspond to the getPatern (or
>>>>> getLocalizable)
>>>>> I asked for a few years ago in ExceptionContext. The point for
>>>>> these
>>>>> methods
>>>>> is that if we provide users a way to retrieve the parameters that
>>>>> were
>>>>> used
>>>>> in the exception construction, then we can delegate localization
>>>>> to
>>>>> users
>>>>> as they can do their own code that will rebuild a complete
>>>>> meaasage as
>>>>> they
>>>>> want. When you have only the keys and they have reused names like
>>>>> OPERATOR
>>>>> or VECTOR, it can't be delegated.
>>>>
>>>> If those are available (as suggested in Ole's example above),
>>>> would you
>>>> indeed
>>>> be OK that localization is not a CM concern anymore?
>>>
>>> Yes at the condition that user can use it to implement something
>>> like
>>> the ExceptionLocalizer interface and this interface is already
>>> supported
>>> by CM exceptions to implement getLocalizedMessage (at least). The
>>> getLocalizedMessage is a standard method inherited directly from
>>> Throwable, it is not an addition from us (on the other hand
>>> getMessage(Locale) *is* an extension I promoted).
>>
>> I don't follow: I thought that if Ole's "MathException" provides
>> "getType",
>> "getKeys" and ("getValues" ?), then you have the same building
>> blocks
>> to define a custom formatting (and localization).
>
> Yes, and this is what is used at user level to implement
> ExceptionLocalizer.

But it is also enough for the wrapper (see above) to do its job.

>>
>> By "dropping support", I mean dropping support. ;-)
>> I.e. no more "Localize..." classes under "org.apache.commons.math4"
>
> Then -1.
>
> When our users build a large application, they rely on numerous
> different libraries and tools, both open-source and proprietary.
> These libraries do have standard interfaces so they can be used
> together. The Java standard library is one of them. the
> getLocalizedMessage method is specified there. Many of the libraries
> and tolls user will assemble rely on it. Deciding that for the sake
> of Apache Commons Math we do not abide to this and decide that all
> other existing code should adapt to a different design is a clear
> no go for me.

Does the JVM abide by this?

The point is that CM code is not user-level code: requirements that
have nothing to do with mathematical algorithms should not have
top-level priority here.  This is what has always biased this
discussion.

This issue is not one of a design that would not use
"getLocalizedMessage"
just that CM is not the place to do so. CM throws exception; caller
handle them in any way they want.
For example:

try {
  // ...

  // Use a low-level library: do not let foreign exceptions bubble up.
  try {
    CMAlgo algo = new CMAlgo();
    algo.run();
  } catch(RuntimeException e) {
    if (e instanceof CMAlgoException)
      throw new MyCMAlgoException(e);
    } else {
      throw new MyUnexpectedException(e);
    }
  }

  // ...
} catch (MyRuntimeException e) {
   LOG.error(e.getLocalizedMessage()); //
}

> Look at it, it is *only* one field with its setter and two one line
> methods defined in the top level MathException class in order to
> abide to a standardized interface widely used.

OK, and I also worked a lot to make it less of a duplication mess.
I don't think that I can oppose you on these 3 lines given all the
work you do. ;-)

But once and for all, I'd like that we acknowledge that this decision
has nothing to do with good design.

>>
>> The list of translated type could still be maintained here, in the
>> same
>> way the unit tests and user guide are.
>
> I'm not sure. If we decide to delegate the localization to the user
> and simply provide the two one-liners hook to call it, then we can
> remove the list of translated types and let the user handle it. It
> would also allow them to support additional languages. For now,
> we support only one, we could drop it using this delegation
> mechanism.

I just meant it as a service to the international of users. :-)
We could centralize the translations as is done for other resources
like
the userguide.

>
>>
>>> This getLocalizedMessage is the standard way many existing
>>> frameworks
>>> use to display the message to end users, and we can't change this
>>> behaviour to have them call the user localization code. So this
>>> user
>>> localization code must lie somewhere beneath the standard
>>> getLocalizedMessage call. The proposal above allow to divert it to
>>> user code with CM providing only the required plumbing (but it must
>>> still provide the plumbing).
>>>
>>>>
>>>> We could provide code of how to perform the translation in the
>>>> userguide.
>>>
>>> Yes.
>>>
>>>>
>>>>> Note that this is independent of the fact there is one or several
>>>>> hierarchies.
>>>>> If there are several ones, the two one-liners above must simply
>>>>> be
>>>>> copied
>>>>> (yeah, code duplication, I know).
>>>>>
>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I think it satisfies everyone's requirements with:
>>>>>>>>>>> - A single MathException (No hierarchy)
>>>>>>>>>> That would not satisfy everyone. :-!
>>>>>>>>>>
>>>>>>>>>>> - The ExceptionTypes Enum contains all the exception types
>>>>>>>>>>> - The ExceptionTypes Enum 'key' maps to the corresponding
>>>>>>>>>>> message 1 to 1
>>>>>>>>>>> - The ExceptionFactory (Utility) throws exceptions, if
>>>>>>>>>>> necessary,
>>>>>>>>>>> that have always have a single unique root cause, such as
>>>>>>>>>>> NPEs
>>>>>>>>>> I was wondering whether the "factory" idea could indeed
>>>>>>>>>> satisfy
>>>>>>>>>> everyone.
>>>>>>>>>> Rather than throwing the non-standard "MathException", the
>>>>>>>>>> factory would
>>>>>>>>>> generate one of the standard exceptions, constructed with
>>>>>>>>>> the
>>>>>>>>>> internal
>>>>>>>>>> "MathException" as its cause:
>>>>>>>>> I think it's good that CM throws CM specific exceptions.  
>>>>>>>>> This way
>>>>>>>>> when I write the handler I can know that the exception is CM
>>>>>>>>> specific
>>>>>>>>> without having to unwrap it.
>>>>>>>> But if there are several CM exceptions hierarchies, the
>>>>>>>> handler
>>>>>>>> will have
>>>>>>>> to check for every base type, leading to more code.
>>>>>>> True dat - but if there are no CM exception hierarchies then
>>>>>>> they
>>>>>>> don't :).
>>>>>> I'd be interested in settling the matter of whether we must use
>>>>>> a
>>>>>> single
>>>>>> hierarchy because of technical limitations, or if it is a good
>>>>>> solution
>>>>>> on its own, i.e. extending standard exceptions is not a better
>>>>>> practice
>>>>>> after all.
>>>>>>
>>>>>>>> We could provide a utility:
>>>>>>>> public boolean isMathException(RuntimeException e) {
>>>>>>>>   if (e instanceof MathException) {
>>>>>>>>     return true;
>>>>>>>>   }
>>>>>>>>   final Throwable t = e.getCause();
>>>>>>>>   if (t != null) {
>>>>>>>>     if (e instanceof MathException) {
>>>>>>>>       return true;
>>>>>>>>     }
>>>>>>>>   }
>>>>>>>>   return false;
>>>>>>>> }
>>>>>>> Or just not wrap.
>>>>>> Of course, but choosing one or the other is not a technical
>>>>>> problem;
>>>>>> it's design decision.  Do we have arguments (or reference to
>>>>>> them)?
>>>>>>
>>>>>>>>>> public class ExceptionFactory {
>>>>>>>>>> public static void
>>>>>>>>>> throwIllegalArgumentException(MathException
>>>>>>>>>> e) {
>>>>>>>>>>     throw new IllegalArgumentException(e);
>>>>>>>>>>   }
>>>>>>>>>> public static void throwNullPointerException(MathException
>>>>>>>>>> e) {
>>>>>>>>>>     throw new NullPointerException(e);
>>>>>>>>>>   }
>>>>>>>>>> // And so on...
>>>>>>>>>> }
>>>>>>>>>> So, CM code would be
>>>>>>>>>> public class Algo {
>>>>>>>>>> public void evaluate(double value) {
>>>>>>>>>>     // Check precondition.
>>>>>>>>>>     final double min = computeMin();
>>>>>>>>>>     if (value < min) {
>>>>>>>>>>       final MathException e = new
>>>>>>>>>> MathException(NUMBER_TOO_SMALL).put(CONSTRAINT,
>>>>>>>>>> min).put(VALUE,
>>>>>>>>>> value);
>>>>>>>>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>>>>>>>>     }
>>>>>>>>>> // Precondition OK.
>>>>>>>>>>   }
>>>>>>>>>> }
>>>>>>>>> Another thing that I hinted to is that the the factory builds
>>>>>>>>> in
>>>>>>>>> the
>>>>>>>>> precondition check in the throw method.  So that the line:
>>>>>>>>> if (value < min) {
>>>>>>>>> can be nixed.
>>>>>>>> It seems nice to ensure that the exception raised is
>>>>>>>> consistent
>>>>>>>> with the
>>>>>>>> checked condition.
>>>>>>> That's the idea.
>>>>>> OK, but do you foresee that all precondition checks will be
>>>>>> handle by
>>>>>> factory methods.
>>>>>> It would not be so nice to have explicit checks sprinkled here
>>>>>> and
>>>>>> there.
>>>>>>
>>>>>>>> Then, a factory method like
>>>>>>>>   throwNotStrictlyPositiveException(Number value, String key)
>>>>>>>> should probably be renamed to
>>>>>>>>   checkNotStrictlyPositiveException(Number value, String key)
>>>>>>> 'check' is good.  I'm going to change it to check.
>>>>>
>>>>> as the name was changed to checkSomething, the last part
>>>>> Exception in
>>>>> the name could be dropped.
>>>>>
>>>>>>>> Also, shouldn't the "key" argument should be optional?
>>>>>>> The key is used to initialize the exception context with the
>>>>>>> Number
>>>>>>> instance.  Different modules could have different keys.  For
>>>>>>> example
>>>>>>> the Arithmetic module has keys X and Y.  So if Y caused the
>>>>>>> exception
>>>>>>> then Y would be passed as the key.  So if we are checking both
>>>>>>> we
>>>>>>> would do this:
>>>>>>> checkNotStrictlyPositiveException(x, X);
>>>>>>> checkNotStrictlyPositiveException(y, Y);
>>>>>>>>
>>>>>>>>>> Then, in an application's code:
>>>>>>>>>> public void appMethod() {
>>>>>>>>>>   // ...
>>>>>>>>>> // Use CM.
>>>>>>>>>>   try {
>>>>>>>>>>     Algo a = new Algo();
>>>>>>>>>>     a.evaluate(2);
>>>>>>>>>>   } catch (IllegalArgumentException iae) {
>>>>>>>>>>     final Throwable cause = iae.getCause();
>>>>>>>>>>     if (cause instanceof MathException) {
>>>>>>>>>>       final MathException e = (MathException) cause;
>>>>>>>>>> // Rethrow an application-specific exception that will make
>>>>>>>>>> more
>>>>>>>>>> sense
>>>>>>>>>>       // to my customers.
>>>>>>>>>>       throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>>>>>>>> e.get(VALUE));
>>>>>>>>>>     }
>>>>>>>>>>   }
>>>>>>>>>> }
>>>>>>>>>> This is all untested.
>>>>>>>>>> Did I miss something?
>>>>>
>>>>> In the code above, if the iae does not have a cause, or if it is
>>>>> not
>>>>> a MathException,
>>>>> the iae should be rethrown.
>>>>
>>>> Indeed!
>>>> The updated code (also unstested):
>>>>
>>>>    try {
>>>>      Algo a = new Algo();
>>>>      a.evaluate(2);
>>>>    } catch (IllegalArgumentException iae) {
>>>>      final MathException e =
>>>> ExceptionFactory.getMathException(iae);
>>>>
>>>>      if (e != null) {
>>>>        // Rethrow an application-specific exception that will make
>>>> more
>>>> sense
>>>>        // to my customers.
>>>>        throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>> e.get(VALUE));
>>>>      } else {
>>>>        throw iae;
>>>>      }
>>>>    }
>>>>
>>>>>>>>> I think you got it all...But the handler will be shorter if
>>>>>>>>> the
>>>>>>>>> exception is not wrapped.
>>>>>>>> But not significantly, I guess.
>>>>>>>> We could also provide
>>>>>>>> public MathException getMathException(RuntimeException e) {
>>>>>>>>   if (e instanceof MathException) {
>>>>>>>>     return (MathException) e;
>>>>>>>>   }
>>>>>>>>   final Throwable t = e.getCause();
>>>>>>>>   if (t != null) {
>>>>>>>>     if (e instanceof MathException) {
>>>>>>>>       return (MathException) e;
>>>>>>>>     }
>>>>>>>>   }
>>>>>>>>   return null;
>>>>>>>> }
>>>>>>>> And then define the other utility as:
>>>>>>>> public boolean isMathException(RuntimeException e) {
>>>>>>>>   return getMathException(e) != null;
>>>>>>>> }
>>>>>>>>
>>>>>>>>> The pattern I'm used to is that libraries
>>>>>>>>> wrap the exceptions of other libraries in order to offer a
>>>>>>>>> standardized facade to the user.  For example Spring wraps
>>>>>>>>> Hibernate
>>>>>>>>> exceptions, since Spring is a layer on top of Hibernate and
>>>>>>>>> other
>>>>>>>>> data
>>>>>>>>> access providers.
>>>>>>>> What do they advertize?  Standard exception, possibly
>>>>>>>> extended, or
>>>>>>>> specific ones, possibly belonging to single hierarchy?
>>>>>>> Spring namespaced - single hierarchy:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/dao/DataAccessException.html
>>>>>>>
>>>>>>>
>>>>>>> BTW - this is blue sky thinking - but Spring Boot has an
>>>>>>> @ExceptionHandler annotation that allows the developer to wire
>>>>>>> up an
>>>>>>> exception handler.  It might be worth exploring something
>>>>>>> similar for
>>>>>>> the purpose of automating I18N requirements.
>>>>>>> @ExceptionHandler(MathException.class)
>>>>>>> someClientCodeThatUsesCM();
>>>>>>
>>>>>> That would be quite necessary I'm afraid. ;-)
>>>>>
>>>>> Not necessarily. The above support for I18N is quite simple.
>>>>
>>>> Maybe too simple... ;-)
>>>> [What did they say about global variables?]
>>>
>>> If the static fields hurts your feelings,
>>
>> It's not just that.
>>
>>> we can always hide
>>> it using an official design pattern like the singleton for
>>> ExceptionFactory, and even use the Initialization-on-demand
>>> holder idiom to store the singleton. Then the localizer would
>>> be an instance field and there would be a static getInstance()
>>> method in the factory. Well, a singleton design pattern plus
>>> a IODH idiom design pattern are really only a global variable
>>> in a pretty dress, so it is only hiding the fact.
>>
>> Unless I'm mistaken, other singletons in CM are initialized by CM,
>> and cannot be changed afterwards.
>>
>>> At the root, yes global variables are frowned upon, but they
>>> do have some use for configuration and making sure some
>>> configuration data can be retrieved from everywhere reliably.
>>> There are many other places were global variables are used in
>>> Java. Just to mention one example that is deirectly related
>>> to our topic, Locale.getDefault() and Locale.setDefault() are
>>> semantically really accesses to a global variable too.
>>
>> I think that this is not something to introduce lightly.
>> When/if we'll want to explore multi-threading, it will add to
>> the problems.
>
> I don't agree at all with this statement.
>
> This is a configuration setting, expected to be called once
> at start time! I cannot see any case with users attempting
> to do it hundreds of time per seconds with different localizers
> to handle localization. This can be documented and users can be
> warned against.
>
> What I do expect is, in cases of server applications, having
> a server answering to remote requests using different languages.
> This is what the new getMessage(Locale) is designed for. Here,
> the locale changes, not the mechanism to support it, and it
> is not a global variable, just a method argument. It is already
> safe in multi-threaded environments.
>
> The setLocalizer method is not a computation algorithm expected
> to be called millions of times and that therefore could experience
> clashes in case of concurrency.

I was not considering this case.
Just the inherent potential problem of a global setter for a
low-level library.
Do you know of other libraries that do such a thing?

Thanks,
Gilles

>
> best regards,
> Luc
>
>> If the localization feature can be achieved without resorting
>> to a global setting, we should favour it.
>>
>> Best,
>> Gilles
>>
>>>
>>> best regards,
>>> Luc
>>>
>>>>
>>>> Best regards,
>>>> Gilles
>>>>
>>>>>
>>>>> best regards,
>>>>> Luc
>>>>>
>>>>>> Best regards,
>>>>>> Gilles
>>>>>>
>>>>>>> Cheers,
>>>>>>> Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Gilles Sadowski
Hi Ole.

At this point in time, there are still incompatible views on the
purpose of an "exception framework" in the context of a library
like CM.

Perhaps you could restate your proposal (on another thread?), and
ask explicitly if people agree with the principle.

If in the affirmative, you should then open an issue on JIRA and
prepare a patch for the master branch, in order to ensure that
there is no hidden problem.


Thanks,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Luc Maisonobe-2
In reply to this post by Gilles Sadowski
Le 24/12/2015 14:13, Gilles a écrit :

> On Thu, 24 Dec 2015 09:36:34 +0100, Luc Maisonobe wrote:
>> Le 24/12/2015 01:41, Gilles a écrit :
>>> On Wed, 23 Dec 2015 20:18:10 +0100, Luc Maisonobe wrote:
>>>> Le 23/12/2015 14:32, Gilles a écrit :
>>>>> Hello.
>>>>>
>>>>> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>>>>>> Le 2015-12-23 01:41, Gilles a écrit :
>>>>>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>>>>>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>>>>>>> Hi.
>>>>>>>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>>>>>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>>>>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> I was considering jumping into the JDKRandomGenerator exception
>>>>>>>>>>>> discussion, but I did not want to hijack it.
>>>>>>>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> [...]
>>>>>>>>>>> But I did not see how localization is handled.
>>>>>>>>>> I did leave localization out.  I think localization was a hard
>>>>>>>>>> requirement in earlier versions of CM, but I'm hoping that
>>>>>>>>>> there is
>>>>>>>>>> some flexibility on this
>>>>>>>>> There was not, since I argued many times to leave it out.
>>>>>>>>> So unless you can show practically how it can work, I have my
>>>>>>>>> doubts
>>>>>>>>> that we'll be allowed to go forward with this approach.
>>>>>>>>>
>>>>>>>>>> and that future versions can defer to a
>>>>>>>>>> utility that uses the ExceptionTypes Enum instance as the key to
>>>>>>>>>> look
>>>>>>>>>> up the internationalized template string.
>>>>>>>>> Looks good.  Where is the code? ;-)
>>>>>>>> So CM clients would:
>>>>>>>> catch(MathException e) {
>>>>>>>>     String exceptionTemplate =
>>>>>>>> ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
>>>>>>>> "US")).getString(e.getType());
>>>>>>>>     String i18Nmessage = buildMessage(exceptionTemplate,
>>>>>>>> e.getContext());
>>>>>>>>     ...
>>>>>>>> }
>>>>>>>> I can prototype that out more.  Just trying to get a feel for how
>>>>>>>> viable the concept is first.
>>>>>>> I'm not sure I understand correctly.
>>>>>>> Does that mean that
>>>>>>> 1. Uncaught exceptions will lead to a message in English?
>>>>>>> 2. Every "catch" must repeat the same calls (although the arguments
>>>>>>> are likely
>>>>>>>    to be the same for all clauses (and for all applications)?
>>>>>>> Comparing this with the current behaviour (where the translated
>>>>>>> message String
>>>>>>> is created when "e.getLocalizedMessage()" is called) is likely to
>>>>>>> make people
>>>>>>> unhappy.
>>>>>>
>>>>>> This could be made simpler with some task delegating between user
>>>>>> code and CM code.
>>>>>> What about :
>>>>>>
>>>>>>  interface ExceptionLocalizer {
>>>>>>     /** Localize an exception message.
>>>>>>       * @param locale locale to use
>>>>>>       * @param me exception to localize
>>>>>>       * @return localized message for the exception
>>>>>>       */
>>>>>>     String localize(Locale locale, MathException me);
>>>>>>  }
>>>>>>
>>>>>> and having ExceptionFactory hold a user-provided implementation of
>>>>>> this interface?
>>>>>>
>>>>>>  public class ExceptionFactory {
>>>>>>
>>>>>>    private static ExceptionLocalizer localizer = new NoOpLocalizer();
>>>>>>
>>>>>>    public static setLocalizer(ExceptionLocalizer l) {
>>>>>>       localizer = l;
>>>>>>    }
>>>>>
>>>>> I think that this is potentially dangerous for two reasons (if I'm
>>>>> not mistaken): it's not thread-safe and it can be called by any
>>>>> library used by the main application.
>>>>
>>>> Intermedaite libraries could also call it, and I hope they would be
>>>> designed to use a consistent way for their own exception (they should
>>>> let the user specify the localization mechanism, use it for themselves
>>>> and pass the configuration to CM).
>>>
>>> I'm not sure I follow.
>>>
>>> IIUC the implications, libraries should be forbidden to call a method
>>> such as "setLocalizer".
>>
>> It's a design choice for the upper libraries, not for CM.
>
> Not for upper libraries, only for the user!
>
> Anyway, the design choice at CM level is: localization or not?
>
> My opinion is that a low-level component should not do localization.
>
> If the exception is a programming error, it is a bug (bad input
> provided by the caller).
> When something like that is encountered, the stack trace must be
> reported to the caller of the method that triggered the exception
> (either application developer, or CM developer).
> I'm sure that a localized detailed message is a nuisance to the
> people who have to debug (what if we provided e.g. Chinese
> translations?).
>
> If people feel that an operator cannot see a CM message in English
> on his console, what do they do to prevent the JVM to show them?
>
> For the few cases in CM that cannot be safe-guarded by precondition
> checks, it's less clear-cut.
> But I still think that localization is a job for a wrapper.
> I.e. if CM would throw an exception instance whose type is a one-to-one
> mapping to a cause, the wrapper has all the info to make a full report
> (in any language).
>
>>>>
>>>> Thread safety here is really not a concern (but we could protect it
>>>> if desired). This setting is a configuration level setting, it is
>>>> usually done once near the beginning of the main program. You don't
>>>> change the mechanism every millisecond.
>>>>
>>>>>
>>>>> I think that the "localizer" instance must be obtained in a way which
>>>>> the end-user controls.
>>>>
>>>> The user controls it. The setLocalizer method can be called directly by
>>>> user, and in fact I expect the user to do it.
>>>
>>> The user is not in control because any code he calls can override the
>>> setting.
>>>
>>>>>>
>>>>>>    public static String localize(Locale locale, MathException me) {
>>>>>>      return localizer.localize(locale, me);
>>>>>>    }
>>>>>>
>>>>>>    /** Default implementation of the localizer that does nothing. */
>>>>>>    private static class NoOpLocalizer implements ExceptionLocalizer {
>>>>>>           /** {@inheritDoc} */
>>>>>>           @Override
>>>>>>           public String localize(MathException me) {
>>>>>>            return me.getMessage();
>>>>>>          }
>>>>>>    }
>>>>>>
>>>>>>  }
>>>>>>
>>>>>> and MathException could implement both getLocalizedMessage() and
>>>>>> even getMessage(Locale) by delegating to the user code:
>>>>>>
>>>>>>   public class MathException {
>>>>>>
>>>>>>     public String getLocalizedMessage() {
>>>>>>       return ExceptionFactory.localize(Locale.getDefault(), this);
>>>>>>     }
>>>>>>
>>>>>>     public String getMessage(Locale locale) {
>>>>>>       return ExceptionFactory.localize(locale, this);
>>>>>>     }
>>>>>>
>>>>>>     ...
>>>>>>
>>>>>>   }
>>>>>>
>>>>>> One thing that would be nice would be that in addition to the get
>>>>>> method,
>>>>>> MathException also provides a getKeys to retrieve all keys and a
>>>>>> getType
>>>>>> to retrieve the type. The later correspond to the getPatern (or
>>>>>> getLocalizable)
>>>>>> I asked for a few years ago in ExceptionContext. The point for these
>>>>>> methods
>>>>>> is that if we provide users a way to retrieve the parameters that
>>>>>> were
>>>>>> used
>>>>>> in the exception construction, then we can delegate localization to
>>>>>> users
>>>>>> as they can do their own code that will rebuild a complete
>>>>>> meaasage as
>>>>>> they
>>>>>> want. When you have only the keys and they have reused names like
>>>>>> OPERATOR
>>>>>> or VECTOR, it can't be delegated.
>>>>>
>>>>> If those are available (as suggested in Ole's example above), would
>>>>> you
>>>>> indeed
>>>>> be OK that localization is not a CM concern anymore?
>>>>
>>>> Yes at the condition that user can use it to implement something like
>>>> the ExceptionLocalizer interface and this interface is already
>>>> supported
>>>> by CM exceptions to implement getLocalizedMessage (at least). The
>>>> getLocalizedMessage is a standard method inherited directly from
>>>> Throwable, it is not an addition from us (on the other hand
>>>> getMessage(Locale) *is* an extension I promoted).
>>>
>>> I don't follow: I thought that if Ole's "MathException" provides
>>> "getType",
>>> "getKeys" and ("getValues" ?), then you have the same building blocks
>>> to define a custom formatting (and localization).
>>
>> Yes, and this is what is used at user level to implement
>> ExceptionLocalizer.
>
> But it is also enough for the wrapper (see above) to do its job.
>
>>>
>>> By "dropping support", I mean dropping support. ;-)
>>> I.e. no more "Localize..." classes under "org.apache.commons.math4"
>>
>> Then -1.
>>
>> When our users build a large application, they rely on numerous
>> different libraries and tools, both open-source and proprietary.
>> These libraries do have standard interfaces so they can be used
>> together. The Java standard library is one of them. the
>> getLocalizedMessage method is specified there. Many of the libraries
>> and tolls user will assemble rely on it. Deciding that for the sake
>> of Apache Commons Math we do not abide to this and decide that all
>> other existing code should adapt to a different design is a clear
>> no go for me.
>
> Does the JVM abide by this?

Yes, as well as JUnit, Eclipse, Maven, and all tools I use.

>
> The point is that CM code is not user-level code: requirements that
> have nothing to do with mathematical algorithms should not have
> top-level priority here.  This is what has always biased this
> discussion.
>
> This issue is not one of a design that would not use "getLocalizedMessage"
> just that CM is not the place to do so. CM throws exception; caller
> handle them in any way they want.
> For example:
>
> try {
>  // ...
>
>  // Use a low-level library: do not let foreign exceptions bubble up.
>  try {
>    CMAlgo algo = new CMAlgo();
>    algo.run();
>  } catch(RuntimeException e) {
>    if (e instanceof CMAlgoException)
>      throw new MyCMAlgoException(e);
>    } else {
>      throw new MyUnexpectedException(e);
>    }
>  }
>
>  // ...
> } catch (MyRuntimeException e) {
>   LOG.error(e.getLocalizedMessage()); //
> }

Times thousands times as CM call in complex applications that do
a lot of math occur everywhere.

>
>> Look at it, it is *only* one field with its setter and two one line
>> methods defined in the top level MathException class in order to
>> abide to a standardized interface widely used.
>
> OK, and I also worked a lot to make it less of a duplication mess.
> I don't think that I can oppose you on these 3 lines given all the
> work you do. ;-)

Thanks.

>
> But once and for all, I'd like that we acknowledge that this decision
> has nothing to do with good design.

I don't claim this to be good design. It is only meant to be practical
and not cumbersome for users.

>
>>>
>>> The list of translated type could still be maintained here, in the same
>>> way the unit tests and user guide are.
>>
>> I'm not sure. If we decide to delegate the localization to the user
>> and simply provide the two one-liners hook to call it, then we can
>> remove the list of translated types and let the user handle it. It
>> would also allow them to support additional languages. For now,
>> we support only one, we could drop it using this delegation mechanism.
>
> I just meant it as a service to the international of users. :-)
> We could centralize the translations as is done for other resources like
> the userguide.

This is fine with me.

>
>>
>>>
>>>> This getLocalizedMessage is the standard way many existing frameworks
>>>> use to display the message to end users, and we can't change this
>>>> behaviour to have them call the user localization code. So this user
>>>> localization code must lie somewhere beneath the standard
>>>> getLocalizedMessage call. The proposal above allow to divert it to
>>>> user code with CM providing only the required plumbing (but it must
>>>> still provide the plumbing).
>>>>
>>>>>
>>>>> We could provide code of how to perform the translation in the
>>>>> userguide.
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>>> Note that this is independent of the fact there is one or several
>>>>>> hierarchies.
>>>>>> If there are several ones, the two one-liners above must simply be
>>>>>> copied
>>>>>> (yeah, code duplication, I know).
>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I think it satisfies everyone's requirements with:
>>>>>>>>>>>> - A single MathException (No hierarchy)
>>>>>>>>>>> That would not satisfy everyone. :-!
>>>>>>>>>>>
>>>>>>>>>>>> - The ExceptionTypes Enum contains all the exception types
>>>>>>>>>>>> - The ExceptionTypes Enum 'key' maps to the corresponding
>>>>>>>>>>>> message 1 to 1
>>>>>>>>>>>> - The ExceptionFactory (Utility) throws exceptions, if
>>>>>>>>>>>> necessary,
>>>>>>>>>>>> that have always have a single unique root cause, such as NPEs
>>>>>>>>>>> I was wondering whether the "factory" idea could indeed satisfy
>>>>>>>>>>> everyone.
>>>>>>>>>>> Rather than throwing the non-standard "MathException", the
>>>>>>>>>>> factory would
>>>>>>>>>>> generate one of the standard exceptions, constructed with the
>>>>>>>>>>> internal
>>>>>>>>>>> "MathException" as its cause:
>>>>>>>>>> I think it's good that CM throws CM specific exceptions.  This
>>>>>>>>>> way
>>>>>>>>>> when I write the handler I can know that the exception is CM
>>>>>>>>>> specific
>>>>>>>>>> without having to unwrap it.
>>>>>>>>> But if there are several CM exceptions hierarchies, the handler
>>>>>>>>> will have
>>>>>>>>> to check for every base type, leading to more code.
>>>>>>>> True dat - but if there are no CM exception hierarchies then they
>>>>>>>> don't :).
>>>>>>> I'd be interested in settling the matter of whether we must use a
>>>>>>> single
>>>>>>> hierarchy because of technical limitations, or if it is a good
>>>>>>> solution
>>>>>>> on its own, i.e. extending standard exceptions is not a better
>>>>>>> practice
>>>>>>> after all.
>>>>>>>
>>>>>>>>> We could provide a utility:
>>>>>>>>> public boolean isMathException(RuntimeException e) {
>>>>>>>>>   if (e instanceof MathException) {
>>>>>>>>>     return true;
>>>>>>>>>   }
>>>>>>>>>   final Throwable t = e.getCause();
>>>>>>>>>   if (t != null) {
>>>>>>>>>     if (e instanceof MathException) {
>>>>>>>>>       return true;
>>>>>>>>>     }
>>>>>>>>>   }
>>>>>>>>>   return false;
>>>>>>>>> }
>>>>>>>> Or just not wrap.
>>>>>>> Of course, but choosing one or the other is not a technical problem;
>>>>>>> it's design decision.  Do we have arguments (or reference to them)?
>>>>>>>
>>>>>>>>>>> public class ExceptionFactory {
>>>>>>>>>>> public static void throwIllegalArgumentException(MathException
>>>>>>>>>>> e) {
>>>>>>>>>>>     throw new IllegalArgumentException(e);
>>>>>>>>>>>   }
>>>>>>>>>>> public static void throwNullPointerException(MathException e) {
>>>>>>>>>>>     throw new NullPointerException(e);
>>>>>>>>>>>   }
>>>>>>>>>>> // And so on...
>>>>>>>>>>> }
>>>>>>>>>>> So, CM code would be
>>>>>>>>>>> public class Algo {
>>>>>>>>>>> public void evaluate(double value) {
>>>>>>>>>>>     // Check precondition.
>>>>>>>>>>>     final double min = computeMin();
>>>>>>>>>>>     if (value < min) {
>>>>>>>>>>>       final MathException e = new
>>>>>>>>>>> MathException(NUMBER_TOO_SMALL).put(CONSTRAINT, min).put(VALUE,
>>>>>>>>>>> value);
>>>>>>>>>>>       ExceptionFactory.throwIllegalArgumentException(e);
>>>>>>>>>>>     }
>>>>>>>>>>> // Precondition OK.
>>>>>>>>>>>   }
>>>>>>>>>>> }
>>>>>>>>>> Another thing that I hinted to is that the the factory builds in
>>>>>>>>>> the
>>>>>>>>>> precondition check in the throw method.  So that the line:
>>>>>>>>>> if (value < min) {
>>>>>>>>>> can be nixed.
>>>>>>>>> It seems nice to ensure that the exception raised is consistent
>>>>>>>>> with the
>>>>>>>>> checked condition.
>>>>>>>> That's the idea.
>>>>>>> OK, but do you foresee that all precondition checks will be
>>>>>>> handle by
>>>>>>> factory methods.
>>>>>>> It would not be so nice to have explicit checks sprinkled here and
>>>>>>> there.
>>>>>>>
>>>>>>>>> Then, a factory method like
>>>>>>>>>   throwNotStrictlyPositiveException(Number value, String key)
>>>>>>>>> should probably be renamed to
>>>>>>>>>   checkNotStrictlyPositiveException(Number value, String key)
>>>>>>>> 'check' is good.  I'm going to change it to check.
>>>>>>
>>>>>> as the name was changed to checkSomething, the last part Exception in
>>>>>> the name could be dropped.
>>>>>>
>>>>>>>>> Also, shouldn't the "key" argument should be optional?
>>>>>>>> The key is used to initialize the exception context with the Number
>>>>>>>> instance.  Different modules could have different keys.  For
>>>>>>>> example
>>>>>>>> the Arithmetic module has keys X and Y.  So if Y caused the
>>>>>>>> exception
>>>>>>>> then Y would be passed as the key.  So if we are checking both we
>>>>>>>> would do this:
>>>>>>>> checkNotStrictlyPositiveException(x, X);
>>>>>>>> checkNotStrictlyPositiveException(y, Y);
>>>>>>>>>
>>>>>>>>>>> Then, in an application's code:
>>>>>>>>>>> public void appMethod() {
>>>>>>>>>>>   // ...
>>>>>>>>>>> // Use CM.
>>>>>>>>>>>   try {
>>>>>>>>>>>     Algo a = new Algo();
>>>>>>>>>>>     a.evaluate(2);
>>>>>>>>>>>   } catch (IllegalArgumentException iae) {
>>>>>>>>>>>     final Throwable cause = iae.getCause();
>>>>>>>>>>>     if (cause instanceof MathException) {
>>>>>>>>>>>       final MathException e = (MathException) cause;
>>>>>>>>>>> // Rethrow an application-specific exception that will make more
>>>>>>>>>>> sense
>>>>>>>>>>>       // to my customers.
>>>>>>>>>>>       throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>>>>>>>>> e.get(VALUE));
>>>>>>>>>>>     }
>>>>>>>>>>>   }
>>>>>>>>>>> }
>>>>>>>>>>> This is all untested.
>>>>>>>>>>> Did I miss something?
>>>>>>
>>>>>> In the code above, if the iae does not have a cause, or if it is not
>>>>>> a MathException,
>>>>>> the iae should be rethrown.
>>>>>
>>>>> Indeed!
>>>>> The updated code (also unstested):
>>>>>
>>>>>    try {
>>>>>      Algo a = new Algo();
>>>>>      a.evaluate(2);
>>>>>    } catch (IllegalArgumentException iae) {
>>>>>      final MathException e = ExceptionFactory.getMathException(iae);
>>>>>
>>>>>      if (e != null) {
>>>>>        // Rethrow an application-specific exception that will make
>>>>> more
>>>>> sense
>>>>>        // to my customers.
>>>>>        throw new InvalidDataInputException(e.get(CONSTRAINT),
>>>>> e.get(VALUE));
>>>>>      } else {
>>>>>        throw iae;
>>>>>      }
>>>>>    }
>>>>>
>>>>>>>>>> I think you got it all...But the handler will be shorter if the
>>>>>>>>>> exception is not wrapped.
>>>>>>>>> But not significantly, I guess.
>>>>>>>>> We could also provide
>>>>>>>>> public MathException getMathException(RuntimeException e) {
>>>>>>>>>   if (e instanceof MathException) {
>>>>>>>>>     return (MathException) e;
>>>>>>>>>   }
>>>>>>>>>   final Throwable t = e.getCause();
>>>>>>>>>   if (t != null) {
>>>>>>>>>     if (e instanceof MathException) {
>>>>>>>>>       return (MathException) e;
>>>>>>>>>     }
>>>>>>>>>   }
>>>>>>>>>   return null;
>>>>>>>>> }
>>>>>>>>> And then define the other utility as:
>>>>>>>>> public boolean isMathException(RuntimeException e) {
>>>>>>>>>   return getMathException(e) != null;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>> The pattern I'm used to is that libraries
>>>>>>>>>> wrap the exceptions of other libraries in order to offer a
>>>>>>>>>> standardized facade to the user.  For example Spring wraps
>>>>>>>>>> Hibernate
>>>>>>>>>> exceptions, since Spring is a layer on top of Hibernate and other
>>>>>>>>>> data
>>>>>>>>>> access providers.
>>>>>>>>> What do they advertize?  Standard exception, possibly extended, or
>>>>>>>>> specific ones, possibly belonging to single hierarchy?
>>>>>>>> Spring namespaced - single hierarchy:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/dao/DataAccessException.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> BTW - this is blue sky thinking - but Spring Boot has an
>>>>>>>> @ExceptionHandler annotation that allows the developer to wire
>>>>>>>> up an
>>>>>>>> exception handler.  It might be worth exploring something
>>>>>>>> similar for
>>>>>>>> the purpose of automating I18N requirements.
>>>>>>>> @ExceptionHandler(MathException.class)
>>>>>>>> someClientCodeThatUsesCM();
>>>>>>>
>>>>>>> That would be quite necessary I'm afraid. ;-)
>>>>>>
>>>>>> Not necessarily. The above support for I18N is quite simple.
>>>>>
>>>>> Maybe too simple... ;-)
>>>>> [What did they say about global variables?]
>>>>
>>>> If the static fields hurts your feelings,
>>>
>>> It's not just that.
>>>
>>>> we can always hide
>>>> it using an official design pattern like the singleton for
>>>> ExceptionFactory, and even use the Initialization-on-demand
>>>> holder idiom to store the singleton. Then the localizer would
>>>> be an instance field and there would be a static getInstance()
>>>> method in the factory. Well, a singleton design pattern plus
>>>> a IODH idiom design pattern are really only a global variable
>>>> in a pretty dress, so it is only hiding the fact.
>>>
>>> Unless I'm mistaken, other singletons in CM are initialized by CM,
>>> and cannot be changed afterwards.
>>>
>>>> At the root, yes global variables are frowned upon, but they
>>>> do have some use for configuration and making sure some
>>>> configuration data can be retrieved from everywhere reliably.
>>>> There are many other places were global variables are used in
>>>> Java. Just to mention one example that is deirectly related
>>>> to our topic, Locale.getDefault() and Locale.setDefault() are
>>>> semantically really accesses to a global variable too.
>>>
>>> I think that this is not something to introduce lightly.
>>> When/if we'll want to explore multi-threading, it will add to
>>> the problems.
>>
>> I don't agree at all with this statement.
>>
>> This is a configuration setting, expected to be called once
>> at start time! I cannot see any case with users attempting
>> to do it hundreds of time per seconds with different localizers
>> to handle localization. This can be documented and users can be
>> warned against.
>>
>> What I do expect is, in cases of server applications, having
>> a server answering to remote requests using different languages.
>> This is what the new getMessage(Locale) is designed for. Here,
>> the locale changes, not the mechanism to support it, and it
>> is not a global variable, just a method argument. It is already
>> safe in multi-threaded environments.
>>
>> The setLocalizer method is not a computation algorithm expected
>> to be called millions of times and that therefore could experience
>> clashes in case of concurrency.
>
> I was not considering this case.
> Just the inherent potential problem of a global setter for a
> low-level library.
> Do you know of other libraries that do such a thing?

At least Orekit (for something called DataProvidersManager, which
is a singleton and uses initialization-on-demand holder idiom),
but this example is biased ;-)

Another example would be log4j2, with the MainMapLookup singleton
and its setMainArguments method that is intended to be called once
with the main arguments, but nothing prevents it to be called
at will (and there are no protections against concurrent accesses).

There is also the JSCH library which uses a private static map for
config and has setters and getters allowing to change its content
(here, there are some protections agains concurrent access).

In many case, as long as you need to store some configuration,
you end up with either a static field (often private and
with getters/setters) or an instance field in a singleton.
It happens in the best libraries.

best regards,
Luc

>
> Thanks,
> Gilles
>
>>
>> best regards,
>> Luc
>>
>>> If the localization feature can be achieved without resorting
>>> to a global setting, we should favour it.
>>>
>>> Best,
>>> Gilles
>>>
>>>>
>>>> best regards,
>>>> Luc
>>>>
>>>>>
>>>>> Best regards,
>>>>> Gilles
>>>>>
>>>>>>
>>>>>> best regards,
>>>>>> Luc
>>>>>>
>>>>>>> Best regards,
>>>>>>> Gilles
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ole
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

ole ersoy
In reply to this post by Gilles Sadowski
Hi Gilles,

It sounds like we're starting to coalesce on this.  Hopefully this is not going to come as too much of a shock :).  [1]  The exception patch will permeate every class that throws an exception.  We will have to delete all the other exception and replace them with MathException.  Here's an example from the ArithmeticUtils refactoring:

https://github.com/firefly-math/firefly-math-arithmetic/blob/master/src/main/java/com/fireflysemantics/math/arithmetic/Arithmetic.java#L582

Notice that the Javadoc has 2 throws declarations containing the same exception using different exception types.

Luc - I think the localization design your created is as elegant as can be.  As far as productivity goes the ExceptionFactory class utilization pattern remains unchanged.  I feel like we just got done stacking 50 wine classes, and I'm not sure I want to move anything, unless I just throw a fork wrench at it in [1] above :).

So suppose we include the MathException with localization.  If anyone is a super purist (Like me) they can just remove the 6 lines of localization code.  Reinstall.  Done.  So from a practical point of view it's about as trivial as it gets.

So the only thing that bugs me about it is that others looking at CM might have the "Why is there localization code in the exception" reaction.  And maybe there is a good reason for that, but having looked at the threads so far, it's not obvious to me that there is.

For example say we have an application exists that throws at 10,000 different points in the App without catching.  So I'm guessing either a server web app or just some app we run from the console. We get a stack trace.  Most of it is in English right (Java vernacular)?  So my gut reaction is that if someone gives me a technical manual in Greek, and it has one sentence in English, that's not so helpful.  This is Java and Math combined.  Anyone looking at it is probably very smart, very confused, or asleep.

Also, the documentation will be updated to say that in order to get translated exception messages, before using CM, set this property on this class.  Or it could say:

-----------------------------------------------------------

In order to translate exception put the following try catch block at the root entry point to your application:

try {
    Application.run()
} catch(MathException e) {
     u.translate(e)
}

This has the same effect, but I think it's a better pattern for developers in general.  The functionality for `u.translate(e)` can be provided in a separate module.  You can do more than just translate the exception.  Move it to a central logging server, etc. I also think makes CM look "Sharper" by advertising the above usage pattern, although everyone knows it's fairly amazing as is.

Cheers,
Ole




On 12/24/2015 08:06 AM, Gilles wrote:

> Hi Ole.
>
> At this point in time, there are still incompatible views on the
> purpose of an "exception framework" in the context of a library
> like CM.
>
> Perhaps you could restate your proposal (on another thread?), and
> ask explicitly if people agree with the principle.
>
> If in the affirmative, you should then open an issue on JIRA and
> prepare a patch for the master branch, in order to ensure that
> there is no hidden problem.
>
>
> Thanks,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> .
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Gilles Sadowski
In reply to this post by Luc Maisonobe-2
On Thu, 24 Dec 2015 16:56:54 +0100, Luc Maisonobe wrote:

>>> [...]
>>>
>>> When our users build a large application, they rely on numerous
>>> different libraries and tools, both open-source and proprietary.
>>> These libraries do have standard interfaces so they can be used
>>> together. The Java standard library is one of them. the
>>> getLocalizedMessage method is specified there. Many of the
>>> libraries
>>> and tolls user will assemble rely on it. Deciding that for the sake
>>> of Apache Commons Math we do not abide to this and decide that all
>>> other existing code should adapt to a different design is a clear
>>> no go for me.
>>
>> Does the JVM abide by this?
>
> Yes,

Then, how to explain that the following code

---CUT---
         for (Locale loc : new Locale[] { Locale.ENGLISH, Locale.FRENCH
}) {
             Locale.setDefault(loc);
             System.out.println("Locale=" + loc);

             try {
                 final int a = 2;
                 double r = a / 0;
             } catch (Exception e) {
                 System.out.println("JVM toString(): " + e);
                 System.out.println("JVM getLocalizedMessage(): " +
e.getLocalizedMessage());
             }

             try {
                 throw new NotStrictlyPositiveException(-1);
             } catch (Exception e) {
                 System.out.println("CM -> toString(): " + e);
                 System.out.println("CM -> getLocalizedMessage(): " +
e.getLocalizedMessage());
             }
         }
---CUT---

produces this output:

---CUT---
Locale=en
JVM toString(): java.lang.ArithmeticException: / by zero
JVM getLocalizedMessage(): / by zero
CM -> toString():
org.apache.commons.math4.exception.NotStrictlyPositiveException: -1 is
smaller than, or equal to, the minimum (0)
CM -> getLocalizedMessage(): -1 is smaller than, or equal to, the
minimum (0)
Locale=fr
JVM toString(): java.lang.ArithmeticException: / by zero
JVM getLocalizedMessage(): / by zero
CM -> toString():
org.apache.commons.math4.exception.NotStrictlyPositiveException: -1
n'est pas strictement plus grand que le minimum (0)
CM -> getLocalizedMessage(): -1 n'est pas strictement plus grand que le
minimum (0)
---CUT---

?

> as well as JUnit, Eclipse, Maven, and all tools I use.
>
>>
>> The point is that CM code is not user-level code: requirements that
>> have nothing to do with mathematical algorithms should not have
>> top-level priority here.  This is what has always biased this
>> discussion.
>>
>> This issue is not one of a design that would not use
>> "getLocalizedMessage"
>> just that CM is not the place to do so. CM throws exception; caller
>> handle them in any way they want.
>> For example:
>>
>> try {
>>  // ...
>>
>>  // Use a low-level library: do not let foreign exceptions bubble
>> up.
>>  try {
>>    CMAlgo algo = new CMAlgo();
>>    algo.run();
>>  } catch(RuntimeException e) {
>>    if (e instanceof CMAlgoException)
>>      throw new MyCMAlgoException(e);
>>    } else {
>>      throw new MyUnexpectedException(e);
>>    }
>>  }
>>
>>  // ...
>> } catch (MyRuntimeException e) {
>>   LOG.error(e.getLocalizedMessage()); //
>> }
>
> Times thousands times as CM call in complex applications that do
> a lot of math occur everywhere.

But you do not have to do the above a thousand times only at the point
where you need to extract the message.

public class MyApp {

   public static void main(String[] args) {
     final Locale loc = new locale(args[0]);
     try {
       final MyApp app = new MyApp(args[1], args[2]);
       app.run();
     } catch (RuntimeException e) {
       if (e instanceof MathException) {
         LOG.error(translate(e, loc));
         exit(1);
       }
     }
   }

   private void run() {
     // ...
   }
}

>>
>>> Look at it, it is *only* one field with its setter and two one line
>>> methods defined in the top level MathException class in order to
>>> abide to a standardized interface widely used.
>>
>> OK, and I also worked a lot to make it less of a duplication mess.
>> I don't think that I can oppose you on these 3 lines given all the
>> work you do. ;-)
>
> Thanks.
>
>>
>> But once and for all, I'd like that we acknowledge that this
>> decision
>> has nothing to do with good design.
>
> I don't claim this to be good design. It is only meant to be
> practical
> and not cumbersome for users.

If it is not practical or cumbersome, then it is not good design. :-)

>>>>
>>>> The list of translated type could still be maintained here, in the
>>>> same
>>>> way the unit tests and user guide are.
>>>
>>> I'm not sure. If we decide to delegate the localization to the user
>>> and simply provide the two one-liners hook to call it, then we can
>>> remove the list of translated types and let the user handle it. It
>>> would also allow them to support additional languages. For now,
>>> we support only one, we could drop it using this delegation
>>> mechanism.
>>
>> I just meant it as a service to the international of users. :-)
>> We could centralize the translations as is done for other resources
>> like
>> the userguide.
>
> This is fine with me.

I'm also fine if we don't provide this service!

>>>> [...]
>>>
>>> The setLocalizer method is not a computation algorithm expected
>>> to be called millions of times and that therefore could experience
>>> clashes in case of concurrency.
>>
>> I was not considering this case.
>> Just the inherent potential problem of a global setter for a
>> low-level library.
>> Do you know of other libraries that do such a thing?
>
> At least Orekit (for something called DataProvidersManager, which
> is a singleton and uses initialization-on-demand holder idiom),
> but this example is biased ;-)
>
> Another example would be log4j2, with the MainMapLookup singleton
> and its setMainArguments method that is intended to be called once
> with the main arguments, but nothing prevents it to be called
> at will (and there are no protections against concurrent accesses).
>
> There is also the JSCH library which uses a private static map for
> config and has setters and getters allowing to change its content
> (here, there are some protections agains concurrent access).
>
> In many case, as long as you need to store some configuration,
> you end up with either a static field (often private and
> with getters/setters) or an instance field in a singleton.
> It happens in the best libraries.

IMHO, this (mis)feature cannot be what makes them "best".
Why is "slf4j" configured the way it is?

Best regards,
Gilles

>>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Luc Maisonobe-2
Le 25/12/2015 04:46, Gilles a écrit :

> On Thu, 24 Dec 2015 16:56:54 +0100, Luc Maisonobe wrote:
>>>> [...]
>>>>
>>>> When our users build a large application, they rely on numerous
>>>> different libraries and tools, both open-source and proprietary.
>>>> These libraries do have standard interfaces so they can be used
>>>> together. The Java standard library is one of them. the
>>>> getLocalizedMessage method is specified there. Many of the libraries
>>>> and tolls user will assemble rely on it. Deciding that for the sake
>>>> of Apache Commons Math we do not abide to this and decide that all
>>>> other existing code should adapt to a different design is a clear
>>>> no go for me.
>>>
>>> Does the JVM abide by this?
>>
>> Yes,
>
> Then, how to explain that the following code
>
> ---CUT---
>         for (Locale loc : new Locale[] { Locale.ENGLISH, Locale.FRENCH }) {
>             Locale.setDefault(loc);
>             System.out.println("Locale=" + loc);
>
>             try {
>                 final int a = 2;
>                 double r = a / 0;
>             } catch (Exception e) {
>                 System.out.println("JVM toString(): " + e);
>                 System.out.println("JVM getLocalizedMessage(): " +
> e.getLocalizedMessage());
>             }
>
>             try {
>                 throw new NotStrictlyPositiveException(-1);
>             } catch (Exception e) {
>                 System.out.println("CM -> toString(): " + e);
>                 System.out.println("CM -> getLocalizedMessage(): " +
> e.getLocalizedMessage());
>             }
>         }
> ---CUT---
>
> produces this output:
>
> ---CUT---
> Locale=en
> JVM toString(): java.lang.ArithmeticException: / by zero
> JVM getLocalizedMessage(): / by zero
> CM -> toString():
> org.apache.commons.math4.exception.NotStrictlyPositiveException: -1 is
> smaller than, or equal to, the minimum (0)
> CM -> getLocalizedMessage(): -1 is smaller than, or equal to, the
> minimum (0)
> Locale=fr
> JVM toString(): java.lang.ArithmeticException: / by zero
> JVM getLocalizedMessage(): / by zero
> CM -> toString():
> org.apache.commons.math4.exception.NotStrictlyPositiveException: -1
> n'est pas strictement plus grand que le minimum (0)
> CM -> getLocalizedMessage(): -1 n'est pas strictement plus grand que le
> minimum (0)
> ---CUT---
>
> ?

I'm confused. If instead of the division by zero I try to open an
inexistent file, the message is translated in French. This is why I
assumed it was properly handled. However, it is also translated using
the regular getMessage(). So I guess the translated message is provided
at lower level by the operating system (Linux in my case) which uses
the LANG environment variable and does not follow the setDefaultLocale
setting.

best regards,
Luc


>
>> as well as JUnit, Eclipse, Maven, and all tools I use.
>>
>>>
>>> The point is that CM code is not user-level code: requirements that
>>> have nothing to do with mathematical algorithms should not have
>>> top-level priority here.  This is what has always biased this
>>> discussion.
>>>
>>> This issue is not one of a design that would not use
>>> "getLocalizedMessage"
>>> just that CM is not the place to do so. CM throws exception; caller
>>> handle them in any way they want.
>>> For example:
>>>
>>> try {
>>>  // ...
>>>
>>>  // Use a low-level library: do not let foreign exceptions bubble up.
>>>  try {
>>>    CMAlgo algo = new CMAlgo();
>>>    algo.run();
>>>  } catch(RuntimeException e) {
>>>    if (e instanceof CMAlgoException)
>>>      throw new MyCMAlgoException(e);
>>>    } else {
>>>      throw new MyUnexpectedException(e);
>>>    }
>>>  }
>>>
>>>  // ...
>>> } catch (MyRuntimeException e) {
>>>   LOG.error(e.getLocalizedMessage()); //
>>> }
>>
>> Times thousands times as CM call in complex applications that do
>> a lot of math occur everywhere.
>
> But you do not have to do the above a thousand times only at the point
> where you need to extract the message.
>
> public class MyApp {
>
>   public static void main(String[] args) {
>     final Locale loc = new locale(args[0]);
>     try {
>       final MyApp app = new MyApp(args[1], args[2]);
>       app.run();
>     } catch (RuntimeException e) {
>       if (e instanceof MathException) {
>         LOG.error(translate(e, loc));
>         exit(1);
>       }
>     }
>   }
>
>   private void run() {
>     // ...
>   }
> }
>
>>>
>>>> Look at it, it is *only* one field with its setter and two one line
>>>> methods defined in the top level MathException class in order to
>>>> abide to a standardized interface widely used.
>>>
>>> OK, and I also worked a lot to make it less of a duplication mess.
>>> I don't think that I can oppose you on these 3 lines given all the
>>> work you do. ;-)
>>
>> Thanks.
>>
>>>
>>> But once and for all, I'd like that we acknowledge that this decision
>>> has nothing to do with good design.
>>
>> I don't claim this to be good design. It is only meant to be practical
>> and not cumbersome for users.
>
> If it is not practical or cumbersome, then it is not good design. :-)
>
>>>>>
>>>>> The list of translated type could still be maintained here, in the
>>>>> same
>>>>> way the unit tests and user guide are.
>>>>
>>>> I'm not sure. If we decide to delegate the localization to the user
>>>> and simply provide the two one-liners hook to call it, then we can
>>>> remove the list of translated types and let the user handle it. It
>>>> would also allow them to support additional languages. For now,
>>>> we support only one, we could drop it using this delegation mechanism.
>>>
>>> I just meant it as a service to the international of users. :-)
>>> We could centralize the translations as is done for other resources like
>>> the userguide.
>>
>> This is fine with me.
>
> I'm also fine if we don't provide this service!
>
>>>>> [...]
>>>>
>>>> The setLocalizer method is not a computation algorithm expected
>>>> to be called millions of times and that therefore could experience
>>>> clashes in case of concurrency.
>>>
>>> I was not considering this case.
>>> Just the inherent potential problem of a global setter for a
>>> low-level library.
>>> Do you know of other libraries that do such a thing?
>>
>> At least Orekit (for something called DataProvidersManager, which
>> is a singleton and uses initialization-on-demand holder idiom),
>> but this example is biased ;-)
>>
>> Another example would be log4j2, with the MainMapLookup singleton
>> and its setMainArguments method that is intended to be called once
>> with the main arguments, but nothing prevents it to be called
>> at will (and there are no protections against concurrent accesses).
>>
>> There is also the JSCH library which uses a private static map for
>> config and has setters and getters allowing to change its content
>> (here, there are some protections agains concurrent access).
>>
>> In many case, as long as you need to store some configuration,
>> you end up with either a static field (often private and
>> with getters/setters) or an instance field in a singleton.
>> It happens in the best libraries.
>
> IMHO, this (mis)feature cannot be what makes them "best".
> Why is "slf4j" configured the way it is?
>
> Best regards,
> Gilles
>
>>>> [...]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Exception Design

Gilles Sadowski
Hello.

On Fri, 25 Dec 2015 10:31:43 +0100, Luc Maisonobe wrote:

> Le 25/12/2015 04:46, Gilles a écrit :
>> On Thu, 24 Dec 2015 16:56:54 +0100, Luc Maisonobe wrote:
>>>>> [...]
>>>>>
>>>>> When our users build a large application, they rely on numerous
>>>>> different libraries and tools, both open-source and proprietary.
>>>>> These libraries do have standard interfaces so they can be used
>>>>> together. The Java standard library is one of them. the
>>>>> getLocalizedMessage method is specified there. Many of the
>>>>> libraries
>>>>> and tolls user will assemble rely on it. Deciding that for the
>>>>> sake
>>>>> of Apache Commons Math we do not abide to this and decide that
>>>>> all
>>>>> other existing code should adapt to a different design is a clear
>>>>> no go for me.
>>>>
>>>> Does the JVM abide by this?
>>>
>>> Yes,
>>
>> Then, how to explain that the following code
>>
>> ---CUT---
>>         for (Locale loc : new Locale[] { Locale.ENGLISH,
>> Locale.FRENCH }) {
>>             Locale.setDefault(loc);
>>             System.out.println("Locale=" + loc);
>>
>>             try {
>>                 final int a = 2;
>>                 double r = a / 0;
>>             } catch (Exception e) {
>>                 System.out.println("JVM toString(): " + e);
>>                 System.out.println("JVM getLocalizedMessage(): " +
>> e.getLocalizedMessage());
>>             }
>>
>>             try {
>>                 throw new NotStrictlyPositiveException(-1);
>>             } catch (Exception e) {
>>                 System.out.println("CM -> toString(): " + e);
>>                 System.out.println("CM -> getLocalizedMessage(): " +
>> e.getLocalizedMessage());
>>             }
>>         }
>> ---CUT---
>>
>> produces this output:
>>
>> ---CUT---
>> Locale=en
>> JVM toString(): java.lang.ArithmeticException: / by zero
>> JVM getLocalizedMessage(): / by zero
>> CM -> toString():
>> org.apache.commons.math4.exception.NotStrictlyPositiveException: -1
>> is
>> smaller than, or equal to, the minimum (0)
>> CM -> getLocalizedMessage(): -1 is smaller than, or equal to, the
>> minimum (0)
>> Locale=fr
>> JVM toString(): java.lang.ArithmeticException: / by zero
>> JVM getLocalizedMessage(): / by zero
>> CM -> toString():
>> org.apache.commons.math4.exception.NotStrictlyPositiveException: -1
>> n'est pas strictement plus grand que le minimum (0)
>> CM -> getLocalizedMessage(): -1 n'est pas strictement plus grand que
>> le
>> minimum (0)
>> ---CUT---
>>
>> ?
>
> I'm confused. If instead of the division by zero I try to open an
> inexistent file, the message is translated in French. This is why I
> assumed it was properly handled. However, it is also translated using
> the regular getMessage(). So I guess the translated message is
> provided
> at lower level by the operating system (Linux in my case) which uses
> the LANG environment variable and does not follow the
> setDefaultLocale
> setting.

I'm not jumping to any conclusion, but I think that this should at
least
let everyone be open to questioning the correctness of having
localization
performed inside CM.

The following page illustrates an approach similar to the one advocated
by Ole and me (i.e. externalize the translation service):
   
http://www.onjava.com/pub/a/onjava/excerpt/javaexIAN3_chap8/index1.html?page=2

It's interesting on (at least) two accounts:
1. Error handling policy of the user might require more than offered by
    the libraries it uses.
    That is if CM offers "internal" localization, a user will still have
to
    try/catch in order to perform all the steps (e.g. logging as Ole
wrote).
2. It is half-baked IMO: Look at the bottom of the page to see what Ole
and
    I were pointing out (mix and match of languages is arguably worse
than
    no localization).

The behaviour of the JVM illustrated above shows that there is no way
to
justify an obligation to _perform_ localization of exceptions.

I fully agree that the existence of "Throwable#getLocalizedMessage()"
is a
hint that libraries should provide a way to _help_ performing
localization.

I think that "getPattern()" which you requested (or "getType()" in
Ole's
new design) fulfills that role.  But there should probably end the
obligation
of CM.
[Looking at it objectively: I hope that if the feature had not existed,
we
would have turned it down like we did with other things deemed not
related
to the core purpose of CM.]

The localizing code is nice now ;-).
It's a fine utility, just that it should be an illustration, or a tool
provided in a separate JAR).

Best,
Gilles

>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]