What are exceptions?

Question

We talk about exception handling everyday. We all konw that it is something that is created when execution meet some unexpected situation.

Here come several questions:

• What is an exception? What's its most low-level in-memory composition? In .NET, I can think of it as some object instance of some exception type. In the native world, what is it made of? Some data sturcures?

• Who create the exception if the exception is not thrown explicitly by the programmer as the following code shows? Is it part of the support that certain language runtime provides?

  SomeException e = new SomeException(); throw e;

• What is the exception working paradigm? Is it true that when some error happens, an instnace of the corresponding data structure/type is created by the language runtime to represent the details of the error?

• How could we know all the possible unexpected situations at runtime and thus create enough exception data structures/types to represent them?

Thanks for your replies.

Answer 1

Traditional error handling methodologies have serious problems:

• Returning an error code from the method requires each and every call to be wrapped into if that checks for the error. This alone would nearly double the codebase and if you forget to do it just once, your program is no longer robust.
• Global error code (a-la errno in C) is not thread-safe.
• Any kind of error code is just a number. It is hard to convey more sophisticated details about the actual error.
• Even if you use "exception structures", it is hard to compose them - different layers of code might use different structures.
• Etc...

Exceptions allow you to:

• Convey rich information about the error, since you are throwing real objects and not just error codes. The type of the object does not have to be predetermined and can "match" the error at the run-time (in fact, one of the major motivations for RTTI in C++ was to determine the run-type type of the thrown exception).
• Decouple error detection from error handling. Error detection is done in a piece of code that has most knowledge about the error (at the bottom of the call hierarchy), while error handling can be done in the much higher layer of code, presumably the one that knows something about UI.
• The code layers in between don't have to know about any of this (but they do need to be written in the "exception safe" way).

---

What is an exception?

An object.

Who create the exception...?

In C++, object is copied before being thrown, since compiler needs to guarantee the lifetime of the exception during stack unwinding, for as long as there is any catch block that can catch it.

In C#, with its garbage collector, we can retain original object even during stack unwinding.

What is the exception working paradigm?

Exceptions model exceptional events. If something is frequent, then it is probably not an exception.

Each kind of error can be represented by an instance of a different class if appropriate. Or you could represent every error with the same class. Or anything in between. There are no hard-and-fast rules.

How could we know all the possible unexpected situations at runtime and thus create enough exception data structures/types to represent them?

You know how your code can fail, so you can design your exceptions appropriately. In a code that other people wrote, assume it can throw anything anytime, unless proven otherwise.

Answer 2

The answers to your questions depend a lot on what language we're talking about.

C doesn't have exceptions at all, although there are proprietary language extensions.
C++ has a way to "throw" an arbitrary object at any point in your code and "catch" it somewhere higher up the call stack.
C# has a way to "throw" objects derived from System.Exception and also "catch" those from higher up the stack. Additionally, I think the .NET runtime reports some issues per throwing an exception itself.

• What is an exception? What's its most low-level in-memory composition? In .NET, I can think of it as some object instance of some exception type. In the native world, what is it made of? Some data sturcures?

In C++, it's simply an arbitrary object, that was created like other objects in code:

throw 42;                     // throws an int object
throw "blah";                 // throws a char[5] object
throw std::string("arg!");    // throws a std::string object
throw my_type(42);            // throws a my_type object
throw std::exception("doh!"); // throws a std::exception object

The matching of thrown exceptions to catch phrases is pretty similar to the matching of overloaded functions. (A big difference is that catch phrases are ordered. That is, the first to match at all will "win" and catch the object. Overloaded functions, however, must always provide an unambiguously best match.)

• Who create the exception if the exception is not thrown explicitly by the programmer as the following code shows? Is it part of the support that certain language runtime provides?

In C++, exceptions can almost only be thrown from code. It could be your own code, someone else's code, some library's code, or the standard library's code. But there will usually have to be a throw statement somewhere. There are a few exceptions (no pun intended) to this, like std::bad_alloc thrown by new (which is likely thrown from a throw statement in code, but I think doesn't have to) and std::bad_cast, thrown from dynamic_cast<>. (Also, the next standard, C++1x, expected next year, allows exceptions to somehow cross thread borders, which probably requires standard library implementors to find a way to store an exception in one thread and rethrow it from another. But I'm pretty hazy on this.)

    SomeException e = new SomeException(); throw e;

In C++ you can, but you rarely ever would want to, throw pointers. You either do

SomeException e; throw e;

or

throw SomeException();

• What is the exception working paradigm? Is it true that when some error happens, an instnace of the corresponding data structure/type is created by the language runtime to represent the details of the error?

There area few places where the C++ standard library throws exceptions, but other than that I can only think of the two features mentioned above (plus the one in C++1x) where the runtime throws exceptions "itself".

• How could we know all the possible unexpected situations at runtime and thus create enough exception data structures/types to represent them?

It's common to only throw objects of classes derived from std::exception in C++, although I have come across code that used their own exception class hierarchy which wasn't rooted in std::exception. The problem with the exception hierarchy in the standard library is that its classes derives non-virtually from each other, which makes it impossible to have your own exception hierarchy shadowing the one from the standard library using multiple inheritance. (Like having your own OutOfRange exception type that inherits from std::out_of_range and from your exception base class MyException, which inherits from std::exception.)

The C++ way to deal with exceptions is mainly based on the following principles:

• Write your code in ways that makes it immune to exceptions thrown at any point. Use RAII and other techniques to achieve that.
• Catch exceptions only at places where you can do something about them.
• Throw exceptions only in exceptionally circumstances. Do not use them for control flow. (C++ exceptions were designed with the goal for vendors to be able to implement them so that the overhead is minimized in the non-exceptional case, at the cost of the exceptional case.)

Answer 3

When the code want to do a operation in computer who can't possible that the certain code thrown an exception.

because we know that if it comes in client system then he can create problem so he use exceptionhandeling to handle the exception.

here is a useful series

http://social.msdn.microsoft.com/Search/en-IN?query=exception+handling&ac=8

Answer 4

First of all, my answer is for C++ only. C does not have exceptions and I am not familiar enough with C# to make statements that include that language as well.

An exception object is just that, an object. It can be an object of some class type, but it can just as easily be an integer. It can be compared somewhat with the return value from a function. The big difference is that storing an exception on the stack is problematic due to the control-flow involved in exception handling.

In C++, all exceptions are always the result of a throw statement. With Microsoft SEH, it is the language-runtime that creates the SEH exceptions. So, there is always some code that creates the exception object.

In C++, the language runtime does not have to know about all possible application-level exceptions that can be thrown. It just has to provide a mechanism that the catch-handler can access (a copy of) the exception object being thrown. How this is achieved is up to the compiler writers.

Answer 5

Exceptions are a way of handing error situations. The alternative are return values, and lots of ifs and switch/cases.

It is true that the exception acts like a hidden goto, but the final code is easier to maintain then it's alternative.

Handling exceptions is fairly easy. All exceptions that are thrown in the code should have a common base class, which logs the error. All exceptions should carry enough information what exactly happened.

It is also true that the exceptions should not be misused in a way that they should be thrown for every little thing. If possible, error should be handled locally. If not, throw an exception which will be caught at the level where the exception can be dealt with.

And the final note : c++ without exceptions is not c++, it is a c with classes

Answer 6

Exceptions are effectively a manner of error handling where it interrupts the flow such that it can no longer continue.

There are two sides to the exception, the thrower and the catcher. The thrower is responsible for detecting that the error has occurred, create an exception class to contain the error information and "throw" it. Pretty much it is like putting it inside a ball and throwing the ball - at this point its job is done and it is up to the "catcher" now.

The catcher is the error-handling mechanism that knows how to handle the error. You may find a catcher only knows how to handle certain types of error. This is handled by the type hierarchy although in my opinion it would be better if this were not done with run-time type information because of the overhead this can cause.

Use of exceptions in normal flow is generally not desirable, eg when you read a file until the end - end-of-file is not an error but an excepted occurrence and should be handled with normal flow not with exceptions.

Answer 7

At its root an exception is a special situation with a predefined handling mechanism. All the rest is up to the implementation.

The type is there because it's convenient to have an object storing extra data on the kind of the special situation. That said an exception could be a controlled switch that would for example just restart a machine each time the hardware can't perform the operation.