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