You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ole Ersoy <ol...@gmail.com> on 2015/12/21 19:14:16 UTC
[math] Exception Design
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Exception Design
Posted by Ole Ersoy <ol...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Exception Design
Posted by Gilles <gi...@harfang.homelinux.org>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Exception Design
Posted by Ole Ersoy <ol...@gmail.com>.
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Exception Design
Posted by Gilles <gi...@harfang.homelinux.org>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org