How are runtime errors handled in a C library compiled in C++?

Question

Suppose I have a C library that I'm linking into a C++ program on Windows using Visual Studio. This C library is black box. If a fatal error occurs in this library (such as dereferencing a null), how will this runtime error be handled by the program/OS? I know in C++ that there are null reference exceptions, so you can probably handle such errors with a try/catch, but since this is a C library it won't issue a throw , right? So what will happen? The program will terminate, but through what means if not a C++ exception?

Answer 1

You can never "handle" dereferencing a null pointer. Once you do this, your program is no longer in a well-defined state, and there is no way to continue deterministically. The only course of action is to terminate() , which the OS will kindly do on your behalf if you have not registered a SIGSEGV handler.

The word "error" has several meanings which could possibly be confusing: On the one hand, a function that is unable to perform its expected task may be said to have encountered an "error", and it would be expected to signal this, either through a suitable return value, or by throwing an exception. This behaviour might better be called a failure . A correct program must be prepared to handle all possible ways in which a function may return. On the other hand, there are programming errors which simply lead to an wrong or even an ill-formed program. A correct program must never have any programming errors.

For example, malloc() may fail (if it cannot find enough space), which it signals by returning a null pointer, but your program would be in error if it dereferenced the result of malloc() without checking.

You can never "catch" or "handle" programming errors with further programming. Instead, a correct program must correctly anticipate and handle all failure conditions of component functions, and recursively a correctly written function must always return in a well-defined manner and signal failure appropriately.

Answer 2

Dereferencing a null pointer in native code will cause an "access violation" on Windows, or a "segmentation fault" on Unix/Linux. Different names for the same thing. It's the CPU that detects the error, and it invokes a handler in the operating system, which terminates the process.

Dereferencing a null reference in a VM-based language (eg .NET or Java) will throw an exception that you can catch. That's possible because the VM sits between the program and the CPU, and it can detect the null before trying to actually dereference it.

AC library is native code, so you'll get an access violation. You'd get the same from a true C++ program, which is also compiled to native code. But if you're using Managed C++ or C++/CLI, those are variants which compile to CIL and run on the .NET runtime, so you get a NullReferenceException in that case.

Answer 3

Support for 'asynchronous' or 'structured' exceptions (such as an invalid memory access) to be caught using the C++ catch keyword is an MSVC extension to the C++ language.

You can catch such exceptions even if they originate from a C function as long as you use the correct compiler option, /EHa : http://msdn.microsoft.com/en-us/library/1deeycx5%28v=VS.100%29.aspx

You could also choose to use Microsoft's 'structured exception' handling language extension (also available in C), which uses the __try and __except keywords: http://msdn.microsoft.com/en-us/library/swezty51.aspx