[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Orekit Users] [POLL] asking users for a proposed change in Orekit
Thanks Luc.
Here is the issue : https://www.orekit.org/forge/issues/484
I think we could continue the discussions (if any) as comments in the issue tracker ?
Yannick
________________________________________
De : orekit-users-request@orekit.org <orekit-users-request@orekit.org> de la part de MAISONOBE Luc <luc.maisonobe@c-s.fr>
Envoyé : mercredi 18 juillet 2018 11:35
À : orekit-users@orekit.org
Objet : Re: [Orekit Users] [POLL] asking users for a proposed change in Orekit
"JEANDROZ, Yannick" <yannick.jeandroz@airbus.com> a écrit :
> Hi Luc,
>
> Sure, we will look into it.
>
> At first glance, I identified the following tasks. Could you please
> confirm I did not forget anything important ?
> - make OrekitException extend RuntimeException
Yes.
> - remove the now unnecessary "throws OrekitException" from all
> Orekit methods signatures
I think so.
> - should I modify the javadoc of all methods previously throwing
> OrekitExceptions ? Or keep the info, which is still useful but could
> become more difficult to maintain ?
To be discussed on either the developers list or the tracker.
From Apache Commons Math experience, maintaining documentation for
exceptions when the compiler does not help because they are unchecked
is a nightmare and never succeeds. You always forgot something.
>
> Process-wise, I guess I should open a new issue in the tracker, and
> move the development-related discussions there ?
Yes, it is the way to go. For long term dicussions that may involve
more than one or two developers, the developers mailing list is
easier than the tracker, but either option is fine. As we will
change our forge in a few weeks, our process may change also, so
there is no definitive rule.
best regards,
Luc
>
> Thank you for your guidance
>
> Yannick
>
> ________________________________________
> De : orekit-users-request@orekit.org
> <orekit-users-request@orekit.org> de la part de MAISONOBE Luc
> <luc.maisonobe@c-s.fr>
> Envoyé : mercredi 18 juillet 2018 09:51
> À : orekit-users@orekit.org
> Objet : Re: [Orekit Users] [POLL] asking users for a proposed change
> in Orekit
>
> Hi all,
>
>
> It seems the result of the poll is clearly towards option 2,
> which is changing orekit exception to unchecekd ones.
>
> Yannick, could your team manage to do the change?
>
> best regards,
> Luc
>
> Hank Grabowski <hankgrabowski@gmail.com> a écrit :
>
>> I'd say I lean towards option #2 as well.
>>
>> On Mon, Jul 16, 2018 at 8:51 AM, Pascal Parraud <pascal.parraud@c-s.fr>
>> wrote:
>>
>>> Hi all,
>>>
>>> As both developper and user of Orekit, I would prefer option 2: it has
>>> several advantages (easiest implementation, backwards-compatible), and I
>>> can't find any major drawback.
>>>
>>> Best regards,
>>>
>>> Pascal
>>>
>>> Le 06/07/2018 à 16:34, MAISONOBE Luc a écrit :
>>>
>>> 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
>>>
>>>
>>>
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.