Re: [Orekit Users] [POLL] asking users for a proposed change in Orekit

["Cefola, Paul" <paulcefo@buffalo.edu>]

Luc,

I would like to suggest that you get an opinion from  Zachary Folcik on this question.  Zach is at folcikz@gmail.com.

It may take him a couple of days to respond.

Paul


---
Dr. Paul J. Cefola
Consultant in Aerospace Systems, Spaceflight Mechanics, & Astrodynamics
Research Scientist,  Dept. of Mechanical and Aerospace Engineering, University at Buffalo (SUNY)

4 Moonstone Way
Vineyard Haven, MA 02568
USA

508-696-1884 (home)
978-201-1393 (mobile)

paulcefo@buffalo.edu
paul.cefola@gmail.com

________________________________________
From: orekit-users-request@orekit.org <orekit-users-request@orekit.org> on behalf of MAISONOBE Luc <luc.maisonobe@c-s.fr>
Sent: Friday, July 6, 2018 10:34 AM
To: orekit-users@orekit.org
Subject: [Orekit Users] [POLL] asking users for a proposed change in Orekit

Hi all,

There is currently a discussion ongoing on the Orekit developers mailing lists
about a proposed change. The decision on what to do exactly depends a lot on
how users that develop applications on top of Orekit use it, so the discussion
should really happen on this list rather than remain on the developers list.

The change is related to error handling. Currently, Orekit has one main
exception, OrekitException. This is a checked exception, so callers (i.e.
you when you develop an application on top of the library) have to either
let it bubble upward up to the main or have to catch it and act accordingly.
As most of Orekit methods declare to throw this exception, most of calling
code as to do this choice: declare or catch.

User code can also sometimes wrap up some Orekit code in other frameworks
and have to respect the API of these frameworks. In this case, the
OrekitException must always be caught and probably wrapped within a
RuntimeException so it is not "seen" by the framework. One typical example
is the use of Java 8 streams and lambda functions, and these do not allow
exception, so some cumbersome wrapping code has to be set up. Here is an
example Yannick Jeandroz sent to start the discussion on the developers
list. As the addMeasurement in the orbit determination estimator can
throw an OrekitEception, he had to write this:

   iMeasurements.stream().forEach(measurement -> {
             try {
                 estimator.addMeasurement(measurement);
             }
             catch (OrekitException e) {
                 throw new RuntimeException(e);
             }
         });

If addMeasurement did not throw a checked exception, this would have
been sufficient, and much more easier to read and maintain:

    Measurements.stream().forEach(measurement ->
estimator.addMeasurement(measurement));

So the point was that OrekitException, as a checked exception, is cumbersome.

Then several options arose during the discussion.

1) The initial proposal was that many exception arise from data
loading (the dreaded
    exception about TAI-UTC history, but also Sun ephemerides, Earth
Orientation Parameters
    and so on). When this happen, it means the caller did not set up
the data configuration
    correctly and nothing can be done. This should rather throw an
unchecked exception and
    the application should be stopped as soon as possible. This
implies some work for
    the Orekit team to sort out the changes to do.

2) Another proposal was to consider that all Orekit exceptions could
be unchecked and
    the basic contract would be: if you use Orekit, you should expect
almost all code
    to throw OrekitException, so at the topmost level, you should be
ready to catch it
    but we will not enforce it. This is the simplest solution, it
almost only implies
    changing

   public class OrekitException extends Exception
into
   public class OrekitException extends RuntimeException

3) A third proposal was to replace some OrekitException with standard
Java exception
    (typically IOException or ParseException for data loading).

4) In parallel to the above, another idea was that as we would change
exceptions,
    we should create a few different exceptions for different errors.
This implies
    a lot of work and would imply not going to the extrem we knew some
years ago
    with Apache Commons Math that was removed when we switched to Hipparchus

5) a counter-proposal to 3) was to use only a small Orekit hierarchy,
thus allowing
    people to catch the top-level Orekit exception and be sure
everything is covered
    as everything would extend this exception, this implies some work
for the Orekit team

6) a slightly different version of idea 4) would be to have only 2 or
3 exceptions,
    maybe one checked, one runtime, one error, this seems to be
relatively easy to
    do


So the point now is as top level users will see these exceptions are
the one that will
need to deal with them, users should have the last word on what should
be done. So
I would like to start a poll on the list to know what users prefer. It
is possible
to mix several ideas. I will start by putting here the current status from the
developers mailing list. Please add your name and preferences. If you
want more
insights, you can read the thread on the developers list, which is public.

  Yannick    : 1 + 6, not opposed to 2
  Luc        : 2 + 5 + 6
  Evan       : leaning towards just 2, though not opposed 1 + 6
  Guilhem    : ? + 3
  Anne-Laure : 1 + 4 + 5 (3 is fine but in a "nice to have" way)

best regards,
Luc