RE: [Orekit Developers] Data-related exceptions

["LUGAN, Anne-Laure [FR]" <anne-laure.lugan@airbus.com>]

Hello every one,

I have been using unchecked exception more and more in the late years... and I have no regret about it!

Against my position, I would like to quote that Eclipse can help to remove partially OrekitException. You can tune Eclipse to raise a compilation warning if the exception is not thrown in the method.
Still, it means, if we migrate only a few OrekitException to unchecked, that we have to remove the "throws OrekitException" one by one, ie each time Eclipse raises a warning through all hierarchy call.

I agree that it would be more helpful to have a few more meaningful Exception than the single OrekitException. 

Best regards,

Anne-Laure

-----Original Message-----
From: orekit-developers-request@orekit.org [mailto:orekit-developers-request@orekit.org] On Behalf Of Guilhem Bonnefille
Sent: Monday, July 02, 2018 5:44 PM
To: orekit-developers@orekit.org
Subject: Re: [Orekit Developers] Data-related exceptions



Le 02/07/2018 à 14:35, MAISONOBE Luc a écrit :
>
> "Ward, Evan" <Evan.Ward@nrl.navy.mil> a écrit :
>
>> Hi Yannick,
>>
>> On Mon, 2018-07-02 at 08:56 +0000, JEANDROZ, Yannick [FR] wrote:
>>
>> I believe this change would allow for a more lightweight code for
>> Orekit users.
>> What are your thoughts about this proposition ? If there is a
>> consensus, I could push the analysis further and begin to tinker with
>> Orekit code.
>>
>> I am OK with making OrekitException a RuntimeException.
>
> Wow, this would be a drastic change! For sure, it would solve Yannick
> (and many others) problem.
>
> What I like in checked exception is that you don't get surprised, the
> compiler prevents you from creating code that does not check for errors.
> However, I do agree that this can go out of hands if the code has many
> internal checks and errors can be raised almost everywhere. So I admit
> that we failed at some points and that as Yannick writes, almost every
> method throws an OrekitException. Therefore, the current code is
> crippled with throws declaration in too many places.
>
> So... I'm on the fence on being convinced to follow Evan drastic
> suggestion.
> What do other people think about this? Could someone push a little
> harder to convince old school developers like me?
>
> If we go this way, should we directly remove the "throws OrekitException"
> declarations and remove the corresponding Javadoc? I think we should,
> because with unchecked exceptions, the tools (IDE, compiler,
> checkstyle...)
> will not help us maintain the consistency of such declarations, and it
> will soon become inconsistent with underlying code.
>

I share the Luc's feeling: checked Exceptions are not bad by design and
cannot be replaced by unchecked ones.

In order to gain full benefit of exceptions, they require lot of
attention, a precise comprehension of use cases and a neat design.

I feel that the current issue is that Orekit should use a more refined
tree of exceptions or use native/standard exceptions, in order to
distinguish different situations and allow each conceptual level to
decide what to do with witch situation. But this needs lot of work (575
occurrences of "throw new OrekitException").

For example, many classes related to file parsing should throw native
IOException (or inherited ones). When dealing directly with the parser,
a developer needs to handle the problem:
- the file does not exist in the current path, so perhaps can I look for
it elsewhere.
- the syntax is wrong? I can ignore the file and look for an other one.
But higher level classes, involving the previous one, should certainly
decide to wrap lower level exceptions into unchecked ones.
As a developer, when dealing with TimeScales, I don't care about
IOException and, as spotted by Yannick, I'm strictly unable to do
anything at this level.

Another way to decide if an exception must be checked or unchecked is to
consider the *contract* of the method. If the caller does not respect
the contract, then we can throw an unchecked one, examples: the
NullPointerException, or the design of the Iterator where the caller is
expected to use hasNext() before calling next().

Hope That Helps.

***************************************************************
Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des informations confidentielles et/ou protegees ou dont la diffusion est restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. Airbus Defence and Space et les sociétés Airbus Group declinent toute responsabilite en cas de corruption par virus, d'alteration ou de falsification de ce courriel lors de sa transmission par voie electronique.
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space and Airbus Group companies disclaim any and all liability if this email transmission was virus corrupted, altered or falsified. 
---------------------------------------------------------------------
Airbus Defence and Space SAS (393 341 516 RCS Toulouse) - Capital: 29.821.072 EUR - Siege social: 31 rue des Cosmonautes, ZI du Palays, 31402 Toulouse cedex 4, France