Catching exceptions

[ajith mk]

Let us assume my friend has designed a library. I am using this library in my code.

Now this library may throw exceptions. As a person who is using it, I may know what to do with those exceptions. But the problem is how do I know which exceptions to anticipate and use them in my catch clause. More generally, what I should do depends on what the exception is. So is it the responsibility of the library designer to tell me what type of exceptions to anticipate?

After catching an exception, my next step naturally is to proceed to examine the data in it. Let us assume the exception has a string in it. Should I also have to know what string values it may have? My question is, how do I deal with arbitrary exception objects.

Finally, a library tries to check the conditions which are required for it to successfully complete the job. If it can't, it throws an exception. If a library neither throws an exception nor completes its job, is it a design error of the library?

Thanks in advance.

[AbstractionAnon]

You will probably get as many opinions on this as there are library designers.

IMO, a library should return as many errors as possible through return values. Exceptions should only be used for exceptional conditions that the library can not handle. e.g. out of memory. If the library can not recover from the error, the probability of your being able to recover from it is not very likely.

So is it the responsibility of the library designer to tell me what type of exceptions to anticipate?

Absolutely.

Let us assume the exception has a string in it. Should I also have to know what string values it may have?

Examining string data is not a very productive way of handling exceptions. The library should have a well thought out exception design that allows you to catch different types of errors with a minimum of effort (few catch clauses). If the library passes a string on an exception, it's probably not expecting you to do any with that string other than displaying it to the user.

My question is, how do I deal with arbitrary exception objects.

Hopefully, all these exception objects inherit from a common exception base class which can catch.

If a library neither throws an exception nor completes its job, is it a design error of the library?

And if the library does not return an error code on an API call, then yes.

[Cubbi]

AbstractionAnon wrote:

If the library can not recover from the error, the probability of your being able to recover from it is not very likely.

That's incorrect: the whole point of exceptions is to let the user of the library recover from the errors that the library doesn't know how to handle. Allocation failure is a great example: if I am writing a word processor or a web server and some low-level library throws std::bad_alloc because the user attempted to open a 4G file or uploaded a swap file, I know exactly how to recover.

[TheIdeasMan]

AbstractionAnon wrote:

IMO, a library should return as many errors as possible through return values.

In the quote below, I think there are a lot of people in the last 2 groups: lots of legacy(that is, existing) code*; fired for using exceptions. But if someone is writing new code, then wouldn't exceptions be better?

*When I say legacy code, I don't mean it's bad: just that for example you already have 1 or more MLOC, retro fitting exceptions to that probably isn't feasible.

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html#a-namere-raiia-e6-use-raii-to-prevent-leaks

CppCoreGuidelines wrote:

Note

But what do we do if we are writing a program where exceptions cannot be used? First challenge that assumption; there are many anti-exceptions myths around. We know of only a few good reasons:

We are on a system so small that the exception support would eat up most of our 2K or memory.
We are in a hard-real-time system and we don’t have tools that allows us that an exception is handled within the required time.
We are in a system with tons of legacy code using lots of pointers in difficult-to-understand ways (in particular without a recognizable ownership strategy) so that exceptions could cause leaks.
We get fired if we challenge our manager’s ancient wisdom

.

[ajith mk]

Actually, even if a library gives us an interface of exceptions to expect, other libraries used in this library may throw some other exceptions. Generally speaking, what type of exceptions to expect from a library is difficult to anticipate especially in large programs.

Having said that, its kind of hard to design catch clauses efficiently without prior agreement between library designer and library user. This actually defeats the the very purpose of exceptions.

That's incorrect: the whole point of exceptions is to let the user of the library recover from the errors that the library doesn't know how to handle. Allocation failure is a great example: if I am writing a word processor or a web server and some low-level library throws std::bad_alloc because the user attempted to open a 4G file or uploaded a swap file, I know exactly how to recover.

How do you recover? When a library throws an exception, it means it can't complete the task. What's the alternative here. It seems exceptions are a way to safely exit the program rather than finding alternatives to get the job done, because designing alternatives requires the knowledge of the exceptions.

So it boils down to this

try
{
....stuff
}
catch(known_exceptions& e)
{
....handle it
}
catch(...)
{
....default action
}

except that 'default action' would be to terminate the program more often than not

[dhayden]

So is it the responsibility of the library designer to tell me what type of exceptions to anticipate?

Yes, absolutely. But you should probably include a catch(...) clause anyway. This is because your friend's documentation of which exceptions can be thrown is probably incomplete.

[Cubbi]

How do you recover? When a library throws an exception, it means it can't complete the task

Correct, and so the code that requested that task (e.g. opening and reading in a file) can now deal that fact: it can tell the user his file was too large to open (or perhaps had some other problem) and return to waiting for more input without crashing and losing their unfinished work.