Re: [Orekit Developers] Preparing release 8.0

[Guilhem Bonnefille <guilhem.bonnefille@c-s.fr>]

Le 04/07/2016 10:49, Luc Maisonobe a écrit :
> Hi Guilhem,
>
> Le 04/07/2016 à 09:44, Guilhem Bonnefille a écrit :
>>
>> Le 24/06/2016 17:10, MAISONOBE Luc a écrit :
>>> This last change would be to get rid of the PropagationException and
>>> replace it with a simple OrekitException. The rationale for this change
>>> is that PropagationException failed to bring any value and just added
>>> complexity. A typical case is used code to implement a step handler.
>>> Such code can only throw PropagationException, not the superclass
>>> OrekitException. However, since that code often uses other Orekit
>>> features (to get PVCoordinates in some frame for example), then users
>>> must wrap the OrekitException thrown from below. We end up with lots
>>> of code like:
>>>
>>>   try {
>>>     // do some Orekit stuff
>>>   } catch (PropagationException pe) {
>>>     // already the good sub-type of exception, just re-throw
>>>     throw pe;
>>>   } catch (OrekitException oe) {
>>>     // wrap the underlying exception
>>>     throw new PropagationException(oe);
>>>   }
>>>
>>> Do you think we could remove this PropagationException? 
>> I'm not sure to understand the change: will the step handler declared
>> throwing an OrekitException or nothing?
> Yes, the step handler is declared to throw an OrekitException. It is
> indeed a checked exception, so decraling it is mandatory.
>
>> If the PropagationException is replaced by OrekitException, doing such
>> change will bring the developer face to a situation where exception can
>> break the logic of the code without being warned because OrekitException
>> are naturally allowed by the signature of step handler.
> I don't understand what you mean here. In any case, the exception was
> allowed and declared, the change is only that we use a single class
> instead of two.
>

Here is my understanding.

When a developer write a new step handler, he has to implement a method
already declared to throw OrekitException. When writing the code of this
method, if a call throws an OrekitException, the compiler/IDE will not
alert the developer because a "solution" exists: the exception is
directly thrown, silently.

Of course it is "simpler" for the developer beause he has nothing to
write to handle this. But in the same time, he is not informed of the
solution selected by the compiler.

I feel this is not the expected behavior of a checked exception. Seems
paradoxal.
Look: if every method in Orekit do the same, there will be no difference
of behavior between an OrekitException and an unchecked exception. ;-)

begin:vcard
fn:Guilhem Bonnefille
n:Bonnefille;Guilhem
org;quoted-printable:CS Syst=C3=A8mes d'Information;Division Espace
adr:;;Parc de la Grande Plaine - 5, rue Brindejonc des Moulinais - BP 15872;Toulouse Cedex 05;;31506;France
email;internet:guilhem.bonnefille@c-s.fr
title:Architecte
tel;work:05 61 17 62 84
url:http://www.c-s.fr/
version:2.1
end:vcard