Undecided between using exceptions or reporting error messages

Question

I'm working on a small project for numerical integration. I've been reading topics like this one and I couldn't decide if I should throw exceptions when the user supplies bad integration limits, requests impossible precision and things like that.

Also, what if a procedure fails to converge for the provided conditions? Should I throw an exception?

Right now what I have are error codes represented in integer variables, which I pass around between many routines, but I'd like to reduce the number of variables the user must declare and whose value they must consult.

I was thinking about a scenario where exceptions are thrown by the library routines in the circumstances I mentioned above and caught by the user. Would that be acceptable? If not, what would be a good approach?

Thanks.

Answer 1

While the question is too broad, I will try to give some general guidance, since this is one of the topics I often talk about.

In general, exceptions are useful when something happened which really shouldn't have happened.

I can give a couple of examples. A programmatic error would be one - when a function call contract is broken, I usually advice throwing an exception rather than returning an error.

An unrecoverable error should trigger an exception, however, judging between recoverable error and non-recoverable error is not always possible at the call site. For example, an attempt to open a non-existing file is usually a recoverable error, which warrants a failure code. But sometimes, the file simply must be there, and there is nothing calling code can do when it is not - so the error becomes unrecoverable. In the latter case, calling code might want the file opening function to throw an exception rather than returning a code.

This introduces the whole topic of exception policies - functions are told if they need to throw exception or return errors.

Answer 2

Before C++11 exceptions were avoided in projects where performance mattered (-fno-exceptions). Now, it appears that exceptions do not impact performance (see this and this), thus there is no reason not to use them.

A paranoid, but old, approach would be: divide your program in two parts, ui and numerical library. UI could be written in any language and use exceptions. Numerical library would be c or c++ and use no exceptions. For instance (win, but doesn't matter), you could have an UI in c# with exceptions that calls an "unsafe" c++ .dll where exceptions are not used.

Alternative to exception is the classic return -1;, the caller has to check return value of every call (even with optional, caller still has to check for errors). When a serie of nested function calls is executed and an error arise in the deepest function, you would have to propagate the error all the way up: you would have to check for errors in every call you do.

With Exceptions, you use a try{} block and that handle errors inside at any call-depth. Code to handle errors appears only once and does not pollute your numerical-library (or whatever you are creating)

Use exceptions!