|
Hi, These mails are very interesting to read, thank you all. This is touching on the “philosophy” of development, I think there is no definitive answer.
But it is really inspiring to read everyone’s experiences. I strongly agree with Evan on one point : my goal when starting this discussion was not to overburden the Orekit maintainers. I think that the
ease of performing the refactoring, and maintaining Orekit afterward should be an important driver of the solution. The current design of exceptions is already quite fine, sometimes “best” is the enemy of “good”. I have taken the liberty to update the poll results : -
added option 6 suggested by Evan, which I believe is slightly different than option 4 -
updated the votes of everyone, according to my understanding of their answers. Do not hesitate to rectify if I did not understood your
position Here are the current results : 1) change a few checked exceptions to unchecked 2) change all checked exceptions to unchecked 3) use standard java exceptions (IOException, ...) 4) create a few different Orekit exception for different errors 5) use a small Orekit hierarchy with an easy to catch top level 6) only 2 or 3 exceptions : (maybe one checked), one runtime, one error Yannick : 1 + 6, not opposed to 2 Luc : hesitating between 1 + 4 + 5 or 2 + 4 + 5 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) Regards Yannick
|