Benefits of exceptions
Exceptions provide the ability to handle or clean up code in a localized place. Also, they allow clean-up code to execute in case of error. The application becomes easier to write and maintain when clean-up code is in a centralized place.
Also—and maybe more importantly—, exceptions can be used to find bugs within the code; because, the CLR walks up the stack of the thread to get the call history. With this, it is possible to find the location of the failure within the code. Further, it is possible to add additional information within the exception, so that a developer can describe the kind of error more precisely.
The biggest problem with exceptions is performance because of some information overhead. So, they should be used only where preemptive programming is inappropriate. Unfortunately, most developers tend to use exceptions improperly—i.e. catch (Exception e); which will be discussed later—or too seldom, so debugging proves harder.
is vs as in C#
This code
bool b = x is Foo;
could be considered as a syntactic sugar for
bool b = (x as Foo) != null;
in which case is is a syntactic sugar for as. Similarly,
Foo f = x as Foo;
could be considered to be a syntactic sugar for
var temp = x;
Foo f = (temp is Foo) ? (Foo)temp : (Foo)null;
in which case as is a syntactic sugar for is. Clearly we cannot have both of these be sugars because then we have an infinite regress!
The specification is clear on this point; as (in the non-dynamic case) is defined as a syntactic sugar for is.
However, in practice the CLR provides us instruction isinst, which ironically acts like as. Therefore we have an instruction which implements the semantics of as pretty well, from which we can build an implementation of is. In short, de jure is is is, and as is as is is, but de facto is is as and as is isinst.
