Do exceptions break encapsulation?

Question

In the first place, a class or library is created when you do not want to worry about the details of an implementation, but then you need to know the inner workings of the class to properly handle the exceptions it might throw.

Doesn't this break the principle of encapsulation and information hiding ? Or I am totally wrong on this ?

Sure I can have a generic try/catch block to intercept all exceptions, but that is definitely a bad practice.

So how can I come up with good exception handling strategy without knowing the details of each exceptions that might be thrown ?

Answer 1

In the first place, a class or library is created when you do not want to worry about the details of an implementation, but then you need to know the inner workings of the class to properly handle the exceptions it might throw.

Doesn't this break the principle of encapsulation and information hiding ? Or I am totally wrong on this ?

An exception should thrown when the calee can't fulfill its promises due to some runtime error and can't recover from that state. What exceptions could be thrown must be specified in the interface/documentation. I don't see how this breaks encapsulation. On the other hand, using return codes can't enforce the caller to treat an exceptional error, even by explicitly ignoring it.

Sure I can have a generic try/catch block to intercept all exceptions, but that is definitely a bad practice.

It is if the designer of the interface you're using didn't clearly specify what exceptions could be thrown and by whom/what_function

So how can I come up with good exception handling strategy without knowing the details of each exceptions that might be thrown ?

The "details" are in fact the exceptions specifications and that's all you need to know. Again, it should be part of documentation/interface.

Anyway, exceptions should happen rarely, probably thats why someone named them exceptions. If it would happen too often then someone wouldn't name them exceptions anymore but "usuality" or something and the normal, exception-free "code" will become an exception :)

If you're working too much with try/catch bollocks then something is wrong with that code.

Answer 2

A well-designed class or library will document what exceptions it throws as part of the interface, perhaps even going so far as to define its own hierarchy of exception classes. For instance, a foo subclass class might throw a "foo persistence exception" if the disk is full, and another subclass would throw one if the network is down. As the caller, you would catch a foo persistence exception because your concern is that data was not persisted. You shouldn't be expected to write code specifically for disk full, network down, disk not present, disk write error, subspace transceiver interference, &c.

It may be the case that you can't do much about many of them.

Answer 3

A class library does not have to throw the same exceptions that its code throws. For expected exceptions that cannot be handled internally, it should probably map to alternate exception types where the "raw" exception would not be readily understood by API consumers. An API consumer should be able to regard expected exceptions as outputs of the API, as one would any other product of usage of the API. Unexpected exceptions, on the other hand, are a whole other ball of wax for both the API developer and consumer...

Answer 4

It's not like that; it's for the end users who are using the end products OR the class "need not to know the inner implementation" but you will know it for sure and hence can hendle the error mechanism accordingly.

BTW, that's the reason any API comes with a good documentation ... so that other developers know at least a bit of it's inner working.

Hopefully this clears the idea.