C++ library which throws many exception types

Question

0.00/5 (No votes)

See more:

Greetings Kind Regards I am writing a C++ library which can throw any number of different exception types. However I am concerned this posses a burden to the library user as he/she will then need to write a long list of catch's. This is my first such project. I seek advice from those w/ more knowledge and experience. Thank You Kindly

To improve: I learned via further experimentation my usage of derived types from std::exception was not performed properly in my original efforts. It is now successful. This question is therefor withdrawn. - Cheerio

What I have tried:

Searched web for advice found nothing helpful. Attempted deriving all exceptions from std::exception and catch(const std::exception& _exception) however this does not permit separate identification as _exception.what() results in "unidentified exception" for derived types.

Posted 6-Aug-22 5:24am

BernardIE5317

Updated 7-Aug-22 4:30am

v2

Add a Solution

Comments

Richard MacCutchan 7-Aug-22 11:24am

"_exception.what() results in "unidentified exception" for derived types."
Then your derivations must be incorrect in some way. I have derived from std::runtime_error (which is derived from std::exception) without problems.

But since we cannot see your implementation it is impossible to make any useful suggestions.

3 solutions

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Richard MacCutchan · Answer 1 · 2022-08-06T05:36:00

Solution 1

The first question that comes to mind is why? If the library throws too many exceptions then maybe you need to rethink your design.

But since you have given no information on what the library is for, it is impossible to be more specific.

Posted 6-Aug-22 5:36am

Richard MacCutchan

Comments

BernardIE5317 6-Aug-22 11:46am

The library throws what I believe logically needs to be thrown. However "too many" is a matter of programming convenience not logic. The two are unrelated or so I believe unless a technical means exists to prevent the caller to the library from needing to write a long list of catch's in order to disambiguate each one. May I please inquire in your long experience have you written a library and if so were multiple exceptions required and if so how were they organized. As for the function of the library I do not see why that is important. Thank You Kindly

Richard MacCutchan 6-Aug-22 12:07pm

Yes I have written more than one library, but the number of exceptions is irrelevant.

And again you have provided no information about your library so your questions are impossible to answer in any specific terms.

BernardIE5317 6-Aug-22 14:59pm

File I/O Do you wish more details?

Greg Utas · Answer 2 · 2022-08-06T05:58:00

Solution 2

Deriving from std::exception is the right approach, so you should override what to provide a unique explanation for each exception.

The STL throws an exception when the user does something invalid, like accessing an element that doesn't exist or using an iterator that has been invalidated. Those are coding errors. But it's not an error to simply look for something that doesn't exist, in which case string returns npos and a container returns cend().

Users shouldn't have to write any catch statements if they're using your library correctly.

Without more detail about what your library does and the kinds of exceptions it throws, it isn't possible to say more.

Posted 6-Aug-22 5:58am

Greg Utas

Comments

BernardIE5317 6-Aug-22 12:08pm

Of course if the user makes no errors then no exceptions will be thrown or need be caught but of course this can not be relied on.

Greg Utas 6-Aug-22 12:13pm

True. But my point is that once the code is correct, it shouldn't be necessary to catch any exceptions. This is a good way to tell whether your library is throwing exceptions appropriately.

BernardIE5317 6-Aug-22 12:25pm

I have difficulty understanding the first statement as it is my understanding it is impossible to determine code is 100% correct w/o error and free of defect so catching exceptions seems a necessity perhaps that is why they ae provided in C++. As for the latter statement I am also again confused as the need to throw exceptions has little to do as near as I can discern w/ the possibility of using the library correctly as doing so can not be guaranteed or assumed.

Greg Utas 6-Aug-22 13:38pm

Exceptions are provided to report errors from which it is impossible to recover. If an exception occurs, it should almost always mean that the code needs to be fixed. Because of this, many programs don't bother to catch exceptions. They just exit and leave it to the designer to debug and fix the problem. But it depends on the type of application. A game would just continue from where it left off. A server would clean up the current transaction and go on to the next one. It's not a question of whether code can be proven to be correct. The point is that correct code shouldn't have to catch exceptions. The library should only throw one when it has no other way to report an error. If code catches exceptions, it is either because it wants to be resilient or improve the way that it reports serious errors.

BernardIE5317 6-Aug-22 14:59pm

"...impossible to recover."? That is not my understanding of the recommendation of one Mr. Stroustrup per https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#e2-throw-an-exception-to-signal-that-a-function-cant-perform-its-assigned-task .

How can one speak of correct code w/o proof of same.

Perhaps the user of my library wishes to be resilient. I assume I should not assume one or the other.

Greg Utas 6-Aug-22 17:51pm

By correct code, I mean correct for the scenario being executed. That doesn't mean correct in every scenario.

Stroustrup's guideline still leaves the design question of what a function's signature should be. If it can be designed to report a failure without throwing an exception, by returning nullptr for example, that is preferable. Returning npos or cend() from find follows this rule. But functions like front or pop_back can't do anything other than thrown an exception if a vector is empty.

BernardIE5317 6-Aug-22 19:00pm

"... for the scenario being executed."?
How does an application writer know what scenarios his/her users will execute?

"... returning nullptr for example, that is preferable."?
To quote Mr. Stroustrup "What good can using exceptions do for me? The basic answer is: Using exceptions for error handling makes you code simpler, cleaner, and less likely to miss errors. But what's wrong with "good old errno and if-statements"? The basic answer is: Using those, your error handling and your normal code are closely intertwined. That way, your code gets messy and it becomes hard to ensure that you have dealt with all errors (think "spaghetti code" or a "rat's nest of tests")."

Of course returning npos or cend() from find makes sense. It is not an error to learn something is not present in a range.

Greg Utas 6-Aug-22 19:53pm

"For the scenario being executed" referred to whether the user's code is correct in a particular scenario. If it is, it shouldn't have to catch exceptions.

Stroustrup's statement still leaves the question of whether an error is severe enough to warrant an exception. When an exception occurs in a live system, you need debugging information to help reproduce the problem. Specifically, you want a stack trace, and getting one is expensive enough that you don't want exceptions to occur in released code. When one occurs, it should be treated as a bug, and the code fixed so that it no longer occurs. Neither the library nor the user's code should cause them during proper operation. There are times that if statements and errno are preferable.

I've written an article, Robust C++: Safety Net, which deals with recovering from exceptions. You might find it useful.

BernardIE5317 6-Aug-22 21:08pm

Is your "user" the application writer i.e. the caller of my library? My "user" is the customer who purchases the application written by the application writer who utilizes my library. This final user's use of the application is unpredictable with infinite possible scenarios.

As for severity of error I do not see it of importance. Errors occur. Presumably they must be reported. What difference the means of doing so. I do not understand why debugging is required merely because an error is reported via exception. If the exact same error were reported via let's say a function return of an error code would debugging not be required? As for debugging I examined the article you kindly provided as near as I can discern the stack trace only provides a list of called functions. I do not see this as very useful. Further in my exception classes I intend to provide the throw'ing function signature and its' arguments as these may be helpful to caller. As for the bulk of the article it is a bit over my head as I do not wish to deal with threads or signals though perhaps I should or leave it to the caller of my library to worry of such things.

Why would if statements and errno be required if the code is found to be correct and free of bugs for a "scenario".

Greg Utas 7-Aug-22 6:32am

The "user" of your library is the application writer.

It's not so much the severity of an error as whether it is expected. The network being unavailable, or the destination being unreachable, is something that can happen even if the code is correct, so these things shouldn't be exceptions. They would be handled with if and errno.

As a library writer, it's unlikely that you should be dealing with threads and signals. That's up to the caller of your library.

OriginalGriff · Answer 3 · 2022-08-06T06:03:00

Richard is pretty much right, the number of exceptions thrown should be appropriate to the task, not a matter of preference.

Exceptions are there to show that something has gone wrong, and it's up to the calling code to decide if it can handle it: if it can, it should - and if it can't it lets "higher level" handle it.

But ... one good way to handle loads of different exceptions in a "simple to handle" way is to nest them: C++ Tutorial => Nested exception[^] so that your system throws a single exception (or two) which contains an inner exception that holds the actual source exception.

For example, if you are given a file path and a password and your job is to decrypt the file and return the content, then there are multiple system exceptions plus decryption problems that could be passed up to the caller. But you could embed all of those in an inner exception and pass up a generic "can't decrypt file" exception that is simple to handle, but provides detail if the caller needs to access it.

C++ library which throws many exception types

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0

C++ library which throws many exception types

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0

Existing Members

...or Join us