C++/c++ & c#
Drawbacks of exception handling in c++ & c#.
i am not a C# programmer; so the following comments are for C++.
in any case, languages like C# and java, that do not have good support for RAII (Resource-Acquisition-Is-Initialization) have no good model for error handling.
case for exceptions:
error handling code tends to be itself error prone, poorly maintained, and under-tested; it tends to get mixed in throughout the program on a line-by-line basis.
reporting failures via return values and status variables, necessitates conditional checks and error handler blocks after every significant function call. robust code using this technique can lead to more than half of a program's code being devoted to error detection and handling.
the vast majority of the time no error is encountered. therefore, the vast majority of error : handling code is completely dead. in addition, it obscures that code which does have value in expressing the program's essential operations. and it can consume valuable computational resources.
typically the caller has two options for handling a failed call:
(1) it can fail itself, or
(2) it can make some modifications and retry the operation (after waiting some time, freeing some resources, etc.).
the vast majority of places in code where errors can be detected don't have the ability or motivation to attempt (2).
exceptions, properly used, make the (1) case automatic and transparent.
any dynamic memory allocation (including ones used by containers and strings from the standard library will throw when allocation fails. operations like 'operator+' requires allocation, and its return value is an object, so there is no way to signal that this allocation failed, except by throwing an exception. similarly, passing a string literal to a function that takes a string type requires an allocation. reading a file into memory requires allocation; so does opening a file. not using exceptions in C++ means you refrain using the standard library, boost, and many other libraries.
many programmers don't know how to handle errors properly no matter what tools you give them. at least exceptions make it easier not to make gross errors.
scoped resource management (with RAII: Resource-Acquisition-Is-Initialization) makes code more robust in the face of errors, and, in general, is superior to garbage collection and try/finally constructs. it does require some discipline and consistency, however. the results are usually well worth it.
case against exceptions:
it is a bad idea to add exceptions to an existing project that has been designed without exceptions in mind.
"Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs" - quoted from google coding guidelines
C++ code using exceptions may not always be significantly simpler, more modular, and easier to maintain. "try" introducing a new scope is a rather unfortunate choice, and that RAII fosters proliferation of types. exceptions have a few ancillary issues: exception specs are statically declared but dynamically checked; recursive throws are result in termination; exceptions are polymorphic but don't offer cloning or visitation primitives.