I recently saw that the boost program_options library throws a logic_error if the command-line input was un-parsable. That challenged my assumptions about logic_error vs. runtime_error.
I assumed that logic errors (logic_error and its derived classes) were problems that resulted from internal failures to adhere to program invariants, often in the form of illegal arguments to internal API's. In that sense they are largely equivalent to ASSERT's, but meant to be used in released code (unlike ASSERT's which are not usually compiled into released code.) They are useful in situations where it is infeasible to integrate separate software components in debug/test builds or the consequences of a failure are such that it is important to give runtime feedback about the invalid invariant condition to the user.
Similarly, I thought that runtime_errors resulted exclusively from runtime conditions outside of the control of the programmer: I/O errors, invalid user input, etc.
However, program_options is obviously heavily (primarily?) used as a means of parsing end-user input, so under my mental model it certainly should throw a runtime_error in the case of bad input.
Where am I going wrong? Do you agree with the boost model of exception typing?
In this case, I think (at least for the most part) you're right and it's wrong. The standard describes logic_error as:
The class logic_error defines the type of objects thrown as exceptions to report errors presumably detectable before the program executes, such as violations of logical preconditions or class invariants.
A command line argument that can't be parsed doesn't seem to fit that very well.
By contrast, it describes runtime_error as:
The class runtime_error defines the type of objects thrown as exceptions to report errors presumably detectable only when the program executes.
That seems to be a better fit.
From a pure standard point of view, you are right. program_options should throw classes derived from either runtime_error or logic_error depending on whether the error is runtime or logical. (I did not review the current code to determine such idea classification for current exceptions).
From a practical standpoint, I have yet to see C++ code that makes useful decisions based on whether exception is logic_error or runtime_error. After all, the only reason you would throw a logic_error as opposed to letting assert file is if you want to try recover somehow, and that's not different from recovery from a runtime error. Personally, I view logic_error vs. runtime_error the same way as checked exceptions in Java -- theoretically nice, but not useful in practice. Which means, that maybe, I'll just make program_options::error derive from exception. That is, when I'll find that 'spare time' everybody keeps talking about.
The current draft of the C++0x Standard says (clause 19.2):
1) In the error model reflected in
these classes (i.e. the exception types), errors are divided into
two broad categories: logic errors and
runtime errors.
2) The distinguishing characteristic
of logic errors is that they are due
to errors in the internal logic of the
program. In theory, they are
preventable.
3) By contrast, runtime errors are due
to events beyond the scope of the
program. They cannot be easily
predicted in advance.
Together with the quotes cited in one of the other answers this explains why Boost.ProgramOptions throws a std::logic_error for preventable errors caused by an 'error presumably detectable before the program executes'.
The user could verify that the file exists, run the program, and suddenly learn that the file has been deleted. That's why an I/O problem is always a runtime_error. Stateful problems are runtime_errors, even if the caller could have checked, since another thread could cause the problem.
logic_error is when the arguments to a function are wrong. It is only for things which could have been caught earlier with stronger type-checking.
So, "missing file" is a runtime_error, but "improperly formatted filename" is a logic_error.
Technically, a logical error within a function is a logic_error too, but if you're smart enough to test for it inside your own function, you should be smart enough to prevent it in the first place.
IMO,
std::logic_error is thrown by a user C++ program logic intentionally. Predicted by a user program.
std::runtime_error is thrown by a C++ runtime (or core part of the langauge…) to abstract lower level errors. Just happens without any intention without involving of any user code.
Related
c++ standard says that logic_error could detect before runtime
while runtime_error detect at runtime.
but how is it working?
My question is how to detect logic_error before runtime.
could you give me some example? thanks for help~!
The C++ standard says this about logic_error (§22.2.2) :
The class logic_error defines the type of objects thrown as exceptions to report errors presumably detectable before the program executes, such as violations of logical preconditions or class invariants.
This does not mean that the exception can be caught at compile time. It means that the cause of the exception could be detected through other means (compiler warnings, code analysis, etc.) at compile time.
I think your misunderstanding is between what causes the exception to be thrown and the exception itself. There are exceptions that cannot be avoided even in a completely bug-free program, for example ones caused by user input. Then there are other exceptions that are clearly caused by writing logically wrong code. Consider this function:
double sqrt(double x); // takes only positive numbers
Now if I use this function like this:
double y = sqrt(-2);
then I made a logic error. I didnt respect the preconditions on the parameter to the function. In such a case it could be the right thing (*) to do for sqrt to throw a std::logic_error (as opposed to a plain runtime_error).
double sqrt(double x) {
if (x < 0) throw std::logic_error();
//....
Now when you read somewhere that "logic errors can be detected before runtime" then this most likely refers to the fact that one can read the code and see that calling sqrt(-2) is indeed wrong and fix it. However, note that this is unrelated to the actual exception being thrown (which is purely a runtime concept).
So to answer your question literally: You detect logic errors in your code by careful analysis. Pay attention to compiler warnings, ask co-workes for a review, use static analysis tools, etc.
(*) = maybe logic_error isnt the perfect thing to throw here, so please take the example with a grain of salt.
Introduction:
In Java, if you do not catch an exception, your code doesn't even compile, and the compiler crashes on unhandled exception.
Question:
Is there a way to tell GCC to be "strict" as Java in this case, and to raise an error or at least a warning on unhandled exception?
If not - are there IDEs (for Unix, please) that can highlight such cases as a warning?
It is not possible in C++. Exception specification is a part of a function declaration but not a part of its type. Any indirect call (via pointer or virtual call) just completely wipes any information about exceptions.
Exception specifications are deprecated anyway in C++11 in favour of noexcept, so it is unlikely any compiler would bother to enhance this language feature.
The only guarantee you can put on a C++ function is that it never throws an exception at all:
void f() noexcept;
However, this will terminate the program at runtime when an exception is thrown. It's not verified at compile-time.
If you want to guarantee that an error is handled, the closest you can get is returning a value of a type that wraps boost::variant<OK, Error> with a member function that takes two callbacks: a callback for the OK case and one for the Error case.
You can ALWAYS use:
int main()
{
try {
... your usual main ...
}
catch(...)
{
std::cerr << "Unhandled exception caught" << std::endl;
}
}
However, that is a fairly poor solution.
Unfortunately, the nature of C++ makes it very hard to catch the situation where something throws an exception and it's not handled, since just about everything has the potential to throw exceptions. I can only think of code-review - perhaps code analyzing tools, such as that built around CLANG will have the capability of doing this, but it probably won't be 100% accurate. In fact, I'm not even sure that the Clang Analyzer fully understands throw/try/catch currently, as it seems to not catch some fairly fundamental errors http://clang-analyzer.llvm.org/potential_checkers.html (see the "exceptions" heading).
First, your statement concerning Java is false; only certain
types of exceptions prevent the code from compiling. And for
the most part, those types of exceptions correspond to things
that are better handled by return codes. Exceptions are normally
only an appropriate solution when propagating an error through
a large number of functions, and you don't want to have to add
exception specifications for all of those functions.
That's really why Java makes its distinctions: exceptions that
derive from java.lang.Error should usually be crashes
(assertion failures and the like in C++); and exceptions that
derive from java.lang.RuntimeException should be exceptions in
C++. Neither are checked in Java, either, because it isn't
reasonable to have every function declare that it might throw
one of them.
As for the rest, the exceptions which you want to catch
immediately in the calling code, they are generally best handled
by return codes, rather than exceptions; Java may use exceptions
here because it has no out arguments, which can make using
return codes more awkward. Of course, in C++, you can also
silently ignore return codes, which is a drawback (but
historical reasons, etc.). But the real issue is the contract,
which is far more complex than function f might throw/return x;
it's more along the lines of "function f will throw/return x,
if condition c is met". And I know of no language which has
a means of enforcing that. In C++ (and for checked exceptions
in Java), exception specifications are more along the lines of
"function f will not throw anything but x". Which is generally
not very useful, unless "x" means all exceptions. In order to
write really robust code, you need a few functions which are
guaranteed never to throw. Interestingly enough, you can
specify this in C++, both pre-C++11 (throw()) and post
(noexcept); you cannot in Java, because you can't specify that
a function won't throw a java.lang.RuntimeError.
(Or a java.lang.Error, but that's less of an issue, since if
you get one of those, you're application is hosed anyway. Just
how are you expected to recover from
java.lang.VirtualMachineError? And of course, you can't
really expect to be able to recover from a segment violation in
C++ either. Although... java.lang.OutOfMemoryError derives
from java.lang.VirtualMachineError; although not easy, and not
always applicable, I've written C++ code which successfully
recovered from std::bad_alloc.)
I just read that in the C++11 standard revision, exception specifications were deprecated. I previously thought specifying what your functions may throw is good practice, but apparently, not so.
After reading Herb Stutter's well-cited article, I cannot help but wonder: why on earth are exception specifications implemented the way they are, and why has the committee decided to deprecate them instead of having them checked at compile-time? Why would a compiler even allow an exception to be thrown which doesn't appear in the function definition? To me, this all sounds like saying "You probably shouldn't specify your function return type, because when you specify int f(), but return 3.5; inside of it, your program will likely crash." (i. e., where is the conceptual difference from strong typing?)
(For the lack of exception specification support in typedefs, given that template syntax is probably Turing-complete, implementing this sounds easy enough.)
The original reason was that it was deemed impossible to
reliably check given the body of existing code, and the fact
that no specifier means anything can throw. Which means that
if static checking was in force, the following code wouldn't
compile:
double
safeSquareRoot( double d ) throw()
{
return d > 0.0 ? sqrt( d ) : 0.0;
}
Also, the purpose of exceptions are to report errors over
a great distance, which means that the intermediate functions
shouldn't know what the functions they call might throw.
Requiring exception specifiers on them would break
encapsulation.
The only real case where a function needs to know about the
exceptions that might occur is to know what exceptions cannot
occur. In particular, it is impossible to write thread safe code
unless you can be guaranteed that some functions will never
throw. Even here, static checking isn't acceptable, for the
reasons explained above, so the exception specification is
designed to work more like an assertion that you cannot
disactivate: when you write throw(), you get more or less the
equivalent of an assertion failure if the function is terminated
by an exception.
The situation in Java is somewhat different. In Java,
there are no real out parameters, which means that if you can't
use return codes if the function also has a return value. The
result is that exceptions are used in a lot of cases where
a return code would be preferable. And these, you do have to
know about, and handle immediately. For things that should
really be exceptions, Java has java.lang.RuntimeException
(which isn't checked, statically or otherwise). And it has no
way of saying that a function cannot ever throw an exception; it
also uses unchecked exceptions (called Error) in cases where
aborting the program would be more appropriate.
If the function f() throw(int) called the function g() throw(int, double) what would happen?
A compile time check would prevent your function from calling any other function with a less strict throw specifier which would be a huge pain.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I just spent a few hours reading through SO questions on the topic of when to use exceptions, and it seems like there are two camps with different point of views:
Use exceptions over error codes
Use error codes most of the time, and exceptions only when some catastrophic error occurs
Is this just a controversial topic with no widely accepted best practice?
As you can probably gather from the wealth of answers, there is certainly no consensus.
Semantically, exceptions and error provide the exact same functionality. Indeed they are identical in about all semantic aspects, and errors can be arbitrarily enriched much like exceptions (you don't have to use a simple code, you can use a real bundle of data!).
The only difference there is is their propagation methods:
errors have to be passed down manually
exceptions are propagated automatically
On the other hand:
the possibility of an error is perfectly documented in the signature
exceptions are silent on code inspection (read GotW #20: Code Complexity and cry) and hidden paths of execution make reasoning harder.
The very reason both solutions can appear clunky is simply that error checking is difficult. Indeed most of the code I am writing daily concerns error checking, whether technical or functional.
So what to do ?
Warning: demonstration ahead, jump over to the next section if you care only for an answer
I personally like to leverage the type system here. The typical example is the pointer-reference dichotomy: a pointer is like a reference that can be null (and reseated, but it does not matter here)
Therefore, instead of:
// Exceptions specifications are better not used in C++
// Those here are just to indicate the presence of exceptions
Object const& Container::search(Key const& key) const throw(NotFound);
I will tend to write:
Object const* Container::search(Key const& key) const;
Or better yet, using clever pointers:
Pointer<Object const> Container::search(Key const& key) const;
template <typename O>
O* Pointer<O>::operator->() const throw(Null);
template <typename O>
O& Pointer<O>::operator*() const throw(Null);
Here I find the use of exception superfluous for 2 reasons:
If we are searching for an object, then there not finding it is both a perfectly common occurrence and there is not much data to carry about: cause of error ? it is not there
The client does not necessarily consider it an error that it is not there, who am I to assume that I know her business better than she does ? Who am I to decide that there will never be a case where it won't be appropriate not to find what was asked for ?
I don't have a problem with exceptions per se, but they can make the code awkward, consider:
void noExceptions(Container const& c)
{
Pointer<Object const> o = c.search("my-item");
if (!o) {
o = c.search("my-other-item");
}
if (!o) { return; } // nothing to be done
// do something with o
}
And compare it with the "exception" case:
void exceptions(Container const& c)
{
Object const* p = 0;
try {
p = &c.search("my-item");
}
catch(NotFound const&) {
try {
p = &c.search("my-other-item");
}
catch(NotFound const&) {
return; // nothing to be done
}
}
// do something with p
}
In this case, the use of exceptions does not seem appropriate :/
On the other hand:
try {
print() << "My cute little baby " << baby.name() << " weighs " << baby.weight();
}
catch(Oupsie const&) {
// deal
}
is certainly more appealing than:
if (!print("My cute little baby ")) { /*deal*/ }
if (!print(baby.name())) { /*deal*/ }
if (!print(" weighs ")) { /*deal*/ }
if (!print(baby.weight())) { /*deal*/ }
What is the best then ?
It depends. Like all engineering problem there is no silver bullet, it's all about concessions.
So keep 2 things in mind:
Error reporting is part of the API
APIs should be designed with ease of use in mind
If you find yourself wondering whether to use an exception or not, just try to use your API. If there is no clear cut winner, it is just that: there is no ideal solution.
Oh, and do not hesitate to refactor your API when it becomes clear that the error reporting mechanism elected at the time of crafting it is no longer appropriate. Don't be ashamed: requirements change with time, so it is normal that the API change with them.
Personally I tend to use exceptions for unrecoverable errors only: I therefore have few try/catch in my code, only in the outermost levels, to accurately log the error (love stack frames) and log a dump of the BOM as well.
This is very similar (and indeed strongly influenced) by Haskell, the code there is seggregated in two clear cut parts: while any can throw exceptions, only the IO part (the extern one) may actually catch them. Therefore, the pure part must deal with error conditions with other ways in case they are "normal".
If, however, I am faced with a problem where using an exception makes the code easier to read and more natural (which is subjective) then I use an exception :)
I don't think this is a discussion which is exclusive to the C++ community, but here are two high-level guidelines which have helped me:
Throw exceptions only in exceptional circumstances. It sounds obvious, but many APIs get built with exceptions being thrown about 50% of the time they are called (and a boolean return status would have been more appropriate).
In your catch clauses, know when to consume exceptions, when to rethrow them as-is and when to throw a different type of exception instead. I can't give you a one-size-fits-all rule for this because it's so dependent on your application's needs, but if you take one thing away from this it should be that the silent consumption of an exception might be the worst thing your code could do. Each frame should have some knowledge of what the calling frame(s) expects when things go wrong.
Exceptions are easier to use than error codes, because they can be thrown by an deeply nested subroutine and intercepted only at the level where it can be handled.
Error codes need to be passed up the chain so every function that calls another has to pass the error code back to its callers.
An error code doesn't have any clear functional advantages over exceptions since an exception can bundle an error code within it. There may have been a time when error codes might be more efficient than exceptions, but I think the cost of the extra code and the difficulty in maintaining it outweighs any possible advantage there.
However, error codes exist in many applications because they are written in, or were ported from, a language that didn't have exceptions, so it makes sense to keep using a uniform approach to error handling.
No, there's no consensus, though.
Edit: As you can see, from the other answers, there's no consensus -- only schools of thought, principles of design, and plans of action. No plan is perfectly suited for every situation.
Even if there were a common consensus, it wouldn't mean it is valid. Your primary consideration here should be the implementation and performance costs. These are both real constraints on the project and the resulting program. In this respect, here are some things to consider.
At runtime, exceptions are more expensive to propagate than simple return values. This is usually the source of the in exceptional cases argument. If you are throwing a lot of exceptions all the time you are suffering a performance penalty. Don't take this to mean exceptions are slow, they are still implemented very efficiently, but nonetheless costlier than error codes.
Exceptions can carry more information than error codes. Something like the boost::exception library allows tagged information which can provide a wealth of useful information up the chain of the exception. Unlike a simple error code saying file not found an exception can carry the filename, the module that tried to load it, and of course the underlying error code. This type of information is very hard to propagate via error codes up the stack.
Error code propagation can be cumbersome at implementation time. Any function that doesn't want to deal with an error has to pass the value up higher. Quite often you'll find code that simply ignores the error since the programmer couldn't deal with it at the time, or he didn't want to refactor his function signatures to pass along the error.
Exception catch syntax is bulky. It is often far easier to check a return code in an if statement than having to write a catch block. If a function has to catch too many differing exceptions at different points, the meaning of the code will be lost in a sea of braces and try/catch clauses. Here is the likely root of the notion that if a function call can normally fail a return code is likely better than an exception.
Understanding clearly how exceptions work will help you in making a decision. There are performance considerations but for many projects this will be negligible. There are concerns about exception safety, you have to know where it is safe and unsafe to use exceptions. Error codes also have the same safety concerns if people start doing short returns from functions.
Understanding the background of your team can also help out; consider if you have two new C++ programmers, one from a C background and the other coming from Java. Some people are more comfortable with error codes, others with exceptions. How far you push either in each direction will impact your project and contribute to the overall quality.
In the end there is no clear answer. While there are some situations where one may clearly win over the other, it highly depends on the project. Look at your code and continue to refactor when appropriate. Sometimes you won't even have an option as to what you use. Other times it'll make no difference. It is highly project specific.
There is most certainly no consensus. At a high level, my mantra is that exceptions should be used in "exceptional cases" - that is, cases that are not a result of programmer error but of unpredictable conditions in the execution environment.
There are volumes of debate surrounding this issue. Depending on other practices in which you engage when writing programs - RAII for example - exceptions may become more or less idiomatically useful.
Exceptions are the only way to properly report errors from a constructor, so the choice is clear there. Throwing an exception forces the caller to catch it and handle it somehow. The alternative design of an empty constructor with an init() method returning an error code is error prone and can lead to objects with an unknown state.
The "C++ community" has factions, each of which has its own opinion about exceptions.
Where I work in the videogame industry, exceptions are forbidden in code that runs on a videogame system. This is because exceptions consume either CPU time OR memory, neither of which a videogame system has any to spare.
Also, in videogames there are few failure cases that warrant graceful recovery; If a videogame fails, human lives or property are not typically at stake.
I like Boost's Error and Exception Handling guidelines. Basically, use exceptions when stack unwinding is desirable. This is simple and unambiguous.
No consensus, but as the replies indicate, many people hold to the view to throw exceptinos only in exceptional circumstances. I don't much like that advice, because then the question becomes "what is an exceptional circumstance?". I prefer the following advice
A function must throw an exception if, and only if, the alternative would be failure to meet a post-condition (including all invariants as implicit post-conditions).
The implementation decision of whether to write throw in your code is then tied to the design decisions of the post-conditions for the function.
See C++ Coding Standards by Herb Sutter and Andrei Alexandrescu, items 70 (Distinguish between errors and non-errors) and 72 (Prefer to use exceptions to report errors).
I did not see this addressed in any other replies, but (as described in the "Effective Java" book) when doing OOP, a possiblity to skip throwing exceptions is to have a helper method in an object to "ask" whether the operation to be done is possible.
For example the hasNext() method on Iterator or Scanner which is usually called before calling the corresponding next*() method.
"We do not use C++ exceptions."
If you don't use exceptions, what happens when there's an error? You just let the program crash?
No, the alternative is to do what people have done for ages in C... you return an error status code that indicates whether the function succeeded or not, and depending on the ways in which it can fail, you might have one or more out parameteters in which you indicate the way in which it failed (or you incorporate the type of failure in the error status code, again it's a case-by-case thing).
Or you could read a little further:
On their face, the benefits of using
exceptions outweigh the costs,
especially in new projects. However,
for existing code, the introduction of
exceptions has implications on all
dependent code. If exceptions can be
propagated beyond a new project, it
also becomes problematic to integrate
the new project into existing
exception-free code. Because most
existing C++ code at Google is not
prepared to deal with exceptions, it
is comparatively difficult to adopt
new code that generates exceptions.
Given that Google's existing code is
not exception-tolerant, the costs of
using exceptions are somewhat greater
than the costs in in a new project.
The conversion process would be slow
and error-prone. We don't believe that
the available alternatives to
exceptions, such as error codes and
assertions, introduce a significant
burden.
Our advice against using exceptions is
not predicated on philosophical or
moral grounds, but practical ones.
Because we'd like to use our
open-source projects at Google and
it's difficult to do so if those
projects use exceptions, we need to
advise against exceptions in Google
open-source projects as well. Things
would probably be different if we had
to do it all over again from scratch.
There is an exception to this rule (no
pun intended) for Windows code.
Alternatives to exceptions other than return codes:
LISP-style conditional handler.
Software signals and slots, QT-style.
Hardware interrupt or signal handler without a stack unwind. It's the stack unwind that is the problem with exceptions on embedded devices.
longjmp / setjmp
Callback function
Flag value e.g. errorno (Unix), GetLastError (Windows), glGetError (OpenGL), etc.
Message queue, if program is event driven
Mutable functor. Handler object as input-output parameter, pointer is changed on error.
Fibers or threads with an error resolution co-routine
asm __int 3 or CPU-equivalent
Overlay instructions or trampoline functions.
...and many more. Many of the above-listed are embedded device friendly.
If you don't use exceptions by definition no code will throw an exception so it will not be needed to be caught.
It's "We do not use C++ exceptions", not "We do not catch C++ exceptions".
The linked style guide explains it well:
On their face, the benefits of using
exceptions outweigh the costs,
especially in new projects. However,
for existing code, the introduction of
exceptions has implications on all
dependent code. If exceptions can be
propagated beyond a new project, it
also becomes problematic to integrate
the new project into existing
exception-free code. Because most
existing C++ code at Google is not
prepared to deal with exceptions, it
is comparatively difficult to adopt
new code that generates exceptions.
It is relatively easy in C++ to create robust code without using exceptions or worrying about Exception Guarantees. With return codes and asserts, exceptions are really limited to programmer errors.
If you're writing code and reach a point where you've identified an issue for which you would typically throw an exception, but wish to abide by some stipulation that exceptions won't be used, then you have to find another way to let the client code know of the error.
As many existing answers document, you could return a sentinel value (e.g. a true/false success value, an enum). This practice is widely familiar from common C functions specified by POSIX and libc, like fopen(), strstr() or printf().
Another important option is to set some internal state that they can query later. Why might you want or need to do the latter? Because some functions, crucially C++ constructors and operators, don't typically give you the opportunity to return an error code. For example, in:
X x1(something), x2(whatever);
fn(x1 + x2);
X::X(...) can't return anything. X::operator+ may be invoked (assuming + isn't invoked on results of conversion operators), but fn() is presumably expecting a const X& (or X&& with C++11), and operator+ needs to return an X so it works in the successful situation. You have no chance to return a distinct type of error code. class X may need to set some internal state that other code (perhaps fn(), perhaps a statement after fn() is called) tests to take appropriate action.
So, you end up with something like:
X x1(something), x2(whatever);
assert(x1.is_valid() and x2.is_valid());
X x3 = x1 + x2;
assert(x3.is_valid());
fn(x3);
Note that this error handling convention is verbose and prone to being overlooked or ignored by client coders - one of the reasons exceptions were created. An interesting variation on this is utilised by most float point hardware - certain operations like division by 0 or under/overflows may set the register to sentinel values such as Not a Number "NaN" or +/- Infinity, and then operations involving an argument in such a state propagate the state to their result. For example, x = 8 + y / 0; z = x + 2; will set z to a sentinel too. The idea here is that you can write code that calculates the correct result whenever possible, and check once before using the result to see if an error from anywhere in the calculation code invalidated that result. It works ok for maths code sometimes, particularly when you're not making branching decisions based on the current values of the variables, but unfortunately in many situations you either won't be able or won't want to make all the users of a potentially invalid object code super-defensively to handle and propagate error states.
Using C++ without exceptions serious compromises the usability, maintainability, concision and elegance of the language.
As an alternative to a total ban on exception usage, in some environments you may be able to catch all exceptions at the boundaries of your API, then return error codes or sentinel values in a "C" style. This allows better coding internally, but better interoperability externally. Sadly, sometimes any use of exceptions is impractical, as your code will execute in an environment where the exception-handling mechanisms aren't provided... perhaps inside a kernel, driver, or embedded environment with a stripped down C++-style compiler. Such an environment is not true C++ though, as it's not Standard compliant.
You use the error-code-returning versions of functions and act according to the return value.