Re: [Orekit Developers] Data-related exceptions

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

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.

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