commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Exceptions from "JDKRandomGenerator"
Date Thu, 24 Dec 2015 01:35:40 GMT
On Wed, 23 Dec 2015 14:08:13 -0600, Ole Ersoy wrote:
> A few drawbacks to having IAE thrown by CM is that it complicates and
> blurres things for those designing a handler that catches all CM
> exceptions.  CM advertising a factory that throws each exception
> 'type' under globally unique conditions minimizes root cause analysis
> time and indirection.
>
> This:
>
>   if (n <= 0) {
>     throw new IllegalArgumentException("n <= 0");
>   }
>
> Misses out on the factory benefit of closing over the condition that
> checks and throws the exception.  It also makes the explanation for
> developing and using CM longer...Is it a
> NOT_STRICTLY_POSITIVE_EXCEPTION or IAE that actually is a
> NOT_STRICTLY_POSITIVE_EXCEPTION exception?
>
> If I know that it's a NOT_STRICTLY_POSITIVE_EXCEPTION then I'm one
> step ahead.  Maybe I can simply set the argument to zero and try
> again, or just throw that step away and continue.

I think that there is a mixing of things:
  1. exception caused by a programming error
  2. exception not caused by a programming error
  3. syntactic sugar (check and throw in one go)

There is the argument that case 1 being a bug, it should not happen and
consequently if an application calls CM with wrong input, it's its 
fault,
not CM's, unless the bug is in CM of course. In either case, the stack
trace pinpoints the bug's location. Once the code is fixed, the 
exception
will not happen again.
Hence why do anything more than throw the exception to stop the code 
where
it is known that there is a problem?
[Arguably, a localized message makes the code harder to debug.]

Using the exception type for control flow is not a good practice. And
assuming that the code can continue after a programming error has been
detected does not look like the best thing to do.

If the error is not a bug, then it makes sense to be able to create a
localized report.

We have to eventually decide whether programming errors _must_ be 
standard
or _can_ be non-standard...

> If we standardizes on using
> Factory.checkNotStrictlyPositiveException(key, n) the client 
> developer
> can also grab the key and the n value and reconstruct the message.
>
> Also, this:
>
> Factory.checkNotStrictlyPositiveException(key, n)
>
> Is easier, more semantic, less error prone, and faster to write than:
>
>   if (n <= 0) {
>     throw new IllegalArgumentException("n <= 0");
>   }
>
> And it provides more benefits:
> - Parameter name(s)
> - Parameter values
> - More semantic
> - Almost instant path to root cause
> - Exception thrown by class (One method call - no unrolling of the
> cause stack)
> - Exception thrown by method (One method call - no unrolling of the
> cause stack)

That's fine with me, as long as all is done so that localization is
gone from CM's main JAR. ;-)


Regards,
Gilles

> Also, if CM modularizes, then the Factory approach standardizes
> exception generation and handling across the entire ecosystem.
>
> Cheers,
> Ole
>
>>> [...]



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message