Le 29/08/2012 20:31, Sébastien Brisard a écrit :
> Hello,
Hi Sébastien,
>
> 2012/8/29 Luc Maisonobe <luc.maison...@free.fr>:
>> Le 29/08/2012 01:40, Gilles Sadowski a écrit :
>>> Hi.
>>
>> Hello,
>>
>>>
>>>>> [...]
>>>>
>>>> I think I get your point, but again given transitive / nested
>>>> dependencies I would not want to depend on it, even if all of the
>>>> components have single-rooted exception hierarchies. This is
>>>> especially true if not all components adhere to the "wrap
>>>> everything" rule - i.e., if they can generate and/or propagate RTEs
>>>> that do not inherit from their base exception class. From the
>>>> standpoint of the caller, for example, what is the difference
>>>> between [math]
>>>>
>>>> 0) throwing IAE
>>>> 1) throwing MathIAE derived from IAE
>>>> 2) throwing MathIAE derived from MathRTE (base)
>>>> assuming that [math] is not signing up to wrap and rethrow every
>>>> exception - including IAE - we get from JDK classes? Will the
>>
>> I was talking only about what we do throw ourselves.
>>
>>>> caller actually do anything different if the RTE is math-wrapped vs
>>>> "naked" but coming out of the [math] code? I understand that the
>>>> try/catch may be several layers removed from the code calling a
>>>> [math] API.
>>>>
>>>> Same applies to NPE, which we don't subclass now, but mostly handle
>>>> as IAE.
>>>>
>>>> I guess one thing we might consider is trying to design for the
>>>> invariant that we never propagate RTEs without wrapping. But that
>>>> would be a lot of work to retrofit and would have a performance cost.
>>>
>>> I don't think that Luc means that we must wrap everyting in a home-made
>>> exception.
>>
>> Gilles is right, I did not intend to catch and wrap everything.
>>
>>>
>>> Two possible cases for NPE:
>>> * The caller passed a "null" reference and will get, sooner or later, an
>>> NPE: it's a bug in his application.
>>> * An NPE was raised by a bug in CM, and we must fix it.
>>>
>>> I think that we should not check for "null" and thus have no use for an NPE
>>> wrapper.
>>
>> I agree. We shouldn' wrap this.
>>
>>>
>>> Are there other "naked" exceptions that could come out of CM?
>>> The policy of extensive precondition checking has the purpose (I think) to
>>> prevent unexpected ("naked" or not) exceptions. If some slip through
>>> nevertheless, doesn't it mean that we miss some check?
>>
>> I think we catch what we need to catch and already have a ggod deal of
>> checking. Of course, we surely missed a few cases, we will fix them when
>> they are identified.
>>
>>>
>>>>
>>>>> Another problem is maintenance. Even if you consider the intermediate
>>>>> developer did his work really accurately and managed to identify all
>>>>> exceptions thrown by the methods he calls in one version of Apache
>>>>> Commons Math. When we change an error detection and decide that a method
>>>>> that did throw only MaxCountExceededException a method should throw
>>>>> NumberIsToolLargeException instead (or in addition to the existing one),
>>>>> then the calling code would still compile, but the new exception would
>>>>> now go all the way upward. The two exceptions have no common ancestor
>>>>> that can be catched, except Exception itself. With a single rooted
>>>>> hierarchy, users can use some defensive programming: they can catch the
>>>>> common root and be safe when we change some internal details.
>>>>>
>>>>> A single root would also bring two things I find useful.
>>>>>
>>>>> The first useful thing is that the ExceptionContextProvider could be
>>>>> implemented at the root level, so we could retrieve this context (in
>>>>> fact, I sometime needs even to retrive the pattern and the arguments
>>>>> from the context, and we also miss getters for that, but they are easy
>>>>> to add). It is not possible to catch ExceptionContextProvider because it
>>>>> is not a throwable (Throwable is a class, not an interface, so we
>>>>> inherit the Throwable nature from the top level class, not as
>>>>> implementing the ExceptionContextProvider interface.
>>>>>
>>>>> The second useful thing is for [math] development itself. With a single
>>>>> root, we can temporarily change its parent class from RuntimeException
>>>>> to Exception, then fix all missing throws declaration and javadoc, then
>>>>> put the parent class back before committing. This would help having more
>>>>> up to date declarations. For now, I am sure we have missed a lot of our
>>>>> own exceptions and let them propagate upward without anybody knowing it.
>>>
>>> "let them propagate upward without anybody knowing it"
>>> What do you mean? [Of course, all CM exceptions propagate upwards; that's
>>> the purpose of raising them in the first place.]
>>> Or did you just mean that the documentation is missing?
>>
>> I meant the documentation is missing.
>>
>>>
>>>>> As a test, I have just changed the parent for
>>>>> MathIllegalArgumentException to Exception. I got 1384 compilation
>>>>> errors. Just going to the first one (a constructor of
>>>>> BaseAbstractUnivariateIntegrator), I saw we did not advertise the fact
>>>>> it may throw NumberIsTooSmallException and NotStrictlyPositiveException,
>>>>> neither in a throws declaration nor in the javadoc. I did not look at
>>>>> the 1383 other errors...
>>>>
>>>> This is a good point.
>>>>>
>>>>>> What I am missing is how knowing that an
>>>>>> aspecific RTE came from within [math] makes a difference. I am
>>>>>> skeptical about ever depending on that kind of conclusion because
>>>>>> dependencies may bring [math] code in at multiple levels. Also, is
>>>>>> there an implied assumption in your ideal setup that *no* exceptions
>>>>>> propagate to [math] clients other than MRTE (i.e. we catch and wrap
>>>>>> everything)?
>>>>> No, I don't make this assumption. I consider that at upper levels, code
>>>>> can receive exception from all layers underneath ([math] at the very
>>>>> bottom, but also other layers in between). With two or three layers, you
>>>>> can still handle a few library-wide exceptions (see my example with
>>>>> MathRuntimeException, and MylibException above). However, if at one
>>>>> level the development rules state that all exception must be caught and
>>>>> wrapped (this happens in some critical systems contexts), then a single
>>>>> root hierarchy helps a lot.
>>>>
>>>> But if we allow some exceptions to propagate unwrapped, this does
>>>> not work, unless I am missing the point here.
>>>
>>> AIUI, when a CM exception is thrown, one (obviously) knows that CM threw it.
>>> When another exception (not a subclass of "MathRuntimeException") is thrown,
>>> it did not come from a "throw" statement written in a CM source file.
>>
>> Right.
>>
>>>
>>>>>
>>>>> My point is that with a single root, we can get the best of two worlds:
>>>>> large scope catches and pinpointed catches. The choice remains open for
>>>>> users. With a multi-rooted hierarchy, we force users to duplicate the
>>>>> same work for all exceptions we may throw, and we also force them to
>>>>> recheck everything when we publish a new version, even despite we
>>>>> ourselves fail to document these exceptions accurately.
>>>>
>>>> We need to fix the documentation. If going back to a single root
>>>> makes automatic detection of gaps possible, that by itself is almost
>>>> enough to get me to agree to go back to the single root. Your
>>>> arguments above (which I honestly only partially follow) are enough
>>>> to make me +0 for this change. I think I probably put too much
>>>> weight on favoring standard exceptions when we are really only
>>>> talking about "reinventing" a handful of them.
>>>
>>> I think that there is no relationship between single root hierarchy and
>>> fixing the documentation...
>>> [Unless we mean to indiscriminately indicate
>>> ---
>>> @throws MathRuntimeException if something goes wrong.
>>> ---
>>> everywhere.]
>>
>> Single root simplifies this. We hage to apply the trick only once.
>>
> I think we had a discussion a few months ago on how exceptions should
> be documented. We came to no agreement at that time, although one
> option (which I followed) was to
> - remove unchecked exceptions from the method's signature
> - add the unchecjked exceptions to the javadoc.
> I agree we should make sure that all exceptions are advertised in the
> javadoc. However, I don't see how Luc's trick can help us in this case
> (if we agree that exceptions should *not* appear in the signature). Am
> I missing something?
No, you are not missing anything. Having only the javadoc without the
declaration in the signature is a pain. I would prefer to keep both. As
I said earlier in this thread, I gave up on the discussion at some time
and did not participate to the last occurrence you point out. I thought
I served a lost cause then.
Luc
>
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
