Coding Principles: why not using checked exceptions

[fortikeco]

Hi,
About the coding principles: why exactly would one use unchecked exceptions over checked exceptions?
I cannot find the motivation behind it and have great difficulty with it in the field of failure-safe engineering. Even the people at Oracle self say:
“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.”

[ndr-brt]

I think this is a topic that caused many discussions and also quarrels during the years over many teams (at least this was my experience).
The best way is to choose an approach and follow it, both of them have pros and cons.

We chosen this one, that makes large use of the Result object pattern to control the flow of the program, while exceptions are used pretty much for exceptional behavior that most of the time cannot be handled (in some languages these are called "errors").

In my humble opinion this approach has these advantages:

• no need to have additional classes (exceptions)
• code is more readable/testable
• less verbose try-catch blocks
• clear distinction between a recoverable error and an unrecoverable one

[fortikeco]

Thanks for your answer!
I guess the decision already has been made, but probably our additions will deviate from that decision.
The exact point of having checked exceptions is actually the reasons you describe (and actually the rest of the world is using them, so I still do not see the point why one would deviate from it).
Reasons to use checked exceptions over unchecked exceptions and Return types:

• no need to have much addiotional classes (you do not need to specify each return type, you can use a pattern to have generic checked exception classes)
• code is more readable/testable (as you can define 1 overall point to cover the handling)
• less verbose in comparison to Result (as there could be only 1 block, whereas with Result you have to check it every single call)
• clear distinction between a recoverable error and an unrecoverable one
• complie-type checks: one is forced to implement error handling, be it in the direct caller or higher in the tree.

[ndr-brt]

• complie-type checks: one is forced to implement error handling, be it in the direct caller or higher in the tree.

this is highlighted with bold like it's a strong point, but in my experience the most way used to handle such situations is:

try {
    component.willThrowsCheckedException()
} catch (CheckedException e) {
    throw new RuntimeException(e);
}

:)

[fortikeco]

So the argument is that junior developers with no java background will introduce technical/design debt anyway? ;-)

[ndr-brt]

I was just showing you that in fact both approaches have pros and cons, and rendering one pros with bold formatting doesn't make it more worthy.