Re: [Orekit Developers] Preparing release 8.0

[Luc Maisonobe <Luc.Maisonobe@c-s.fr>]

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.

best regards,
Luc


>