Do checked exceptions violate the open closed principle?

Question

I have two checked exceptions: TestException1 and TestException2 and the following code:

void p1() throws TestException1{
    p2();
}

void p2() throws TestException1 { 
    p3();
}

void p3() throws TestException1 {}

Does the editing of the signature of p3 as follows violate the Open-Closed principle?

void p3() throws TestException1, TestException2 {}

Because p3() is closed to extension. Any extension(in this case adding a new checked exception to throw) of p3 implies the edit of p2() and p1() signatures. — Overflow 404, Feb 26 '19 at 13:55
Oh, I didn't see p2 called p3. I wouldn't call adding exceptions to an existing method a violation of the Open-Closed principle since it doesn't impact the software design as much as version compatability, which is more of an architectural concern. — daniu, Feb 26 '19 at 14:12

Stephen C · Accepted Answer · 2021-07-05T06:57:50.507

I think I understand what you mean by your question now. (2nd attempt)

Strictly speaking, any change that you make to the source code of a class violates the "closed" part of the open closed principle. The significance of the violation depends on nature of the change.

In your example, changing the checked exceptions thrown by a public API method in Java is a significant violation. It is liable to lead to compilation errors in any method that uses the methods ... or Error subclass exceptions cause by binary compatibility problems if you don't recompile. Indeed, since p3 is called by p2 and indirectly by p1, you actually need to change more of the class to get it to compile. This may make the scope of the API change larger.

So to your question:

Do checked exceptions violate the open closed principle?

Not exactly.

Checked exceptions can be used without violating the open closed principle. However, adding a checked exception to an API method that has been "frozen" does violate the principle¹. But it is the act of adding the exception that is the violation ... not the exception itself, or checked exceptions in general.

^{1 - And even this is debatable. The counter is that fixing design flaws and bugs does not violate the open closed principle.}

"_Any change that you make to the source code of a class violates the "closed" part_ ", is too strict. Bertrand Meyer makes notable exceptions, e.g. "_If you have control over the original software and can rewrite it so that it will address the needs of several kinds of client at no extra complication, you should do so._" And also, "_Neither the Open-Closed principle nor redefinition in inheritance is a way to address design flaws, let alone bugs. If there is something wrong with a module, you should fix it_". — jaco0646, Mar 03 '19 at 16:24

score 3 · Answer 2 · answered Mar 01 '19 at 23:26

No, checked exceptions do not violate OCP, for the simple reason that OCP applies to modules, not to methods.

If you consider a checked exception is just another piece of a method signature, this question is the same as whether method names or method parameters or method return types violate OCP. The principle simply does not apply at this granular level.

Without knowing how the method is implemented, or more importantly, how the method is exposed via its module's API, we have nothing to judge. For example, a method may rely on a hard-coded constant; but if the method can be overridden by clients, it is still open for extension. Nothing about the existence of a checked exception informs us whether or not a module is extensible.

On the other hand if checked exceptions caused a method to be final, and if such a method was exposed by a module as part of its public API, and if that module provided no alternative to that API, then it would be an OCP violation.

It's not true. Meyer Bertrand(1988) in his book Object-Oriented Software Construction states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification". — Overflow 404, Mar 03 '19 at 08:56
Please provide a page number for the quote. I am looking at the 1997 second edition of the book, which I believe supercedes the original. OCP is defined on page 57-61. It is defined consistently in terms of modules. That sentence is more likely from Robert Martin's 1995 article where he paraphrases Meyer. Martin gives a more "mature" explanation in his linked blog post from 2014, which consistently uses modules. — jaco0646, Mar 03 '19 at 16:09

Do checked exceptions violate the open closed principle?

2 Answers2