"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Wednesday, August 20, 2003

Checked Exceptions and Encapsulation

Are checked exceptions a good thing? Do they break encapsulation?

Consider an analogy.

I don't think checked exceptions are necessary. I think they can provide value.

But the cost of maintenance of static checking in Java is not worth the cost. What is my evidence?

I am more productive in Jython, which is capable of dynamically handling checked exceptions at runtime without the cost of static checking.

Let me illustrate my point with an analogy.

Consider an application command processor. The application has many functional areas. Each functional area has multiple commands that can be processed.

I can define a command abstraction and a command processor that works on the abstraction, independent of the specifics of any one command and any functional area.

In this case the commands are encapsulated and the command processor only has to be written once. New commands can be added at any time.

Now say the commands have names. And say that optionally a command can be designated as "checked", i.e. that at compile time the command processor must declare its awareness that some functional area is providing such commands.

Has encapsulation been broken? No. The problem is that named encapsulations are checked at compile time.

Is this a good thing? You decide the value.

Does it have a cost? Yes. The command processor has to be updated whenever a checked command is added to the system.

No comments:

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.