unchecked exception why ? why ?

[Eclesia]

Hello,

I'm a bit stunned by the choice made to used only unchecked exceptions in jackson 3. And would like too know a bit more on the reasons. I've read https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-4 but didn't find any of the argument very convincing. The only I can agree on is the case of checked exceptions in Stream classes which is painful I confess, but non the less necessary to be handle properly.

So far I use jackson in many projects and made an implementation of mapper/factory/builder for UBJSON.

I've been around in the java world for like ~20years and my last experience with a full unchecked exception library was OrientDB. It was a nightmare, at some point we decided not to trust any function call from it, and so try-catch everywhere. And we dropped the lib completely after 2 projects (for this and other reasons)

I sincerely hope you will mark in the documentation on all and every class and method which one may throw or must never throw a runtimexception. But even then we will not be able to thrust the implementation completely.

Again I can only advice you to reconsider this choice. By choosing unchecked exceptions you are lowering the constraints controls over all implementation on the jackson API, leaving everyone free to throw whatever runtime exception anytime they want. Maintenance is going to be more painful for you too.

Just my 2cents.

[cowtowncoder]

Development cycle for 3.0.0 was about 7 years (and this change was done almost 5 years ago -- see FasterXML/jackson-core#661) -- and release candidate cycle 6 months , so everyone interested has had their chance to discuss this change before 3.0.0 GA.

I have zero interest in re-litigating this change. All I can say is that:

1. Change was strongly requested by many users,
2. I am aware of "holy wars" b/w checked vs unchecked exceptions
3. My impression has been that Java community overall has been moving away from checked exceptions (for years I was advocate for checked exceptions myself; this is why 1.0 API used them)
4. Given (2) there is literally no way please everyone
5. My personal reason for change of heart is the functional aspect (not just for Java 8 Streams although mostly) -- there was so much noise in translating checked IOExceptions into unchecked alternative -- that any benefit for documentation purposes seem moot.

Now that 3.0.0 GA is out, this change/decision is permanent and neither can nor should be changed -- in 3.x it cannot, wrt (Semantic) versioning, and there are no plans for another major version (possibly ever)

I will leave the discussion open for others to have their say but above is my bit.