[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orekit Developers] Data-related exceptions



Hello,

 

I have a minor concern about the handling of exceptions in Orekit. It might have been discussed before, if this is the case please do not hesitate to show me the previous discussions.

 

Some context first : since Java 8 introduced some elements of functional programming, I have attempted to use them whenever it makes sense. Basically, Java 8 streams and lambda expressions are useful to execute operations over elements of a collection, potentially filtering them in the process. Although the Java API has a few quirks, I find that the resulting code is generally less bug-prone (no more indexing issues) and more maintainable than a plain old "for" loop. For instance, here is a little one-liner (indented on 3 lines for readability) that returns the set of visible ground stations from a list of stations and a SpacecraftState :

 

Set<GroundSource> visibleStations = internals.values().stream()

                                                                                                                .filter(station -> station.isVisible(spacecraftState))

                                                                                                                .collect(Collectors.toSet());

 

 

The main issue I have is that lambda expressions cannot handle checked exceptions very well : they become much more verbose, which kind of defeats the point :

 

iMeasurements.stream().forEach(measurement -> {

            try {

                estimator.addMeasurement(measurement);

            }

            catch (OrekitException e) {

                throw new RuntimeException(e);

            }

        });

 

The above could be greatly simplified if “addMeasurement” did not throw an Exception :

 

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

 

 

In Orekit, many (nearly all) methods throw OrekitExceptions. There are lots of cases where it is perfectly justified. However, it seems to me that a significant proportion of exceptions are related to model data being unavailable. I am not sure that throwing a checked exception in this case is the best thing to do. The library user should have ensured that orekit-data is initialized before attempting to use it. This means that if the exception is thrown, something has most likely gone wrong with initialization, and the software will likely not be able to do anything more to correct it.

 

Oracle guideline regarding checked exceptions is : "If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception." (http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html)

 

My first idea, which could probably be refined, would be to change all orekit data-related exceptions into unchecked exceptions. Maybe a custom exception, or maybe a MissingResourceException with a descriptive error message ? This way, the exception can still be caught or thrown if desired, but this is not mandatory anymore (the exception is then thrown, by default). I believe this change would not break backward compatibility, however many IDEs are configured to raise a warning when the developer explicitly throws an unchecked exception (basically writing code that is not necessary). So some users could suddenly get many warnings in their projects.

 

 

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.

 

Thanks

Yannick

***************************************************************
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