This site uses cookies for analytics, personalized content. By continuing to browse this site, you agree to this use. Learn More
Free. Cross-platform. Open source. A developer platform for building all your apps.
February 20, 2009Feb 20, 200902/20/09
The March installment of the “CLR Inside Out” column in MSDN magazine is now available on line. This month we have an article from Justin Van Patten on Isolated Storage in Silverligth 2.
You can find a list of all “CLR Inside Out”
February 20, 2009Feb 20, 200902/20/09
As Andrew pointed out in his recent post, the February installment of the “CLR Inside Out” column in MSDN magazine is now available on line. This month we have an article from Andrew Pardoe on Handling Corrupted State Exceptions.
You can find a list of all “CLR Inside Out”
February 19, 2009Feb 19, 200902/19/09
You’ve seen the advice before—it’s not a good programming practice to catch System.Exception. Because managed exceptions are hierarchical, catching the top of the hierarchy—e.g., catch(Exception)—is an easy way to make sure that you catch all exceptions. But do you really want to catch all exceptions?
February 19, 2009Feb 19, 200902/19/09
You’ve seen the advice before—it’s not a good programming practice to catch System.Exception. Because managed exceptions are hierarchical, catching the top of the hierarchy—e.g., catch(Exception)—is an easy way to make sure that you catch all exceptions. But do you really want to catch all exceptions?
February 5, 2009Feb 5, 200902/5/09
A very common pattern in the usage of managed exception handling is that of catching an exception, inspecting it’s type and rethrowing it once you realize it was not the exception you wanted to handle. Below is such an example (and should be avoided in preference to another approach described further below in the writeup) that uses CustomBaseException as the base type of an exception hierarchy and CustomDontWantToCatchException as a type that derives from the base class that you wouldn’t want to catch:
February 5, 2009Feb 5, 200902/5/09
A very common pattern in the usage of managed exception handling is that of catching an exception, inspecting it’s type and rethrowing it once you realize it was not the exception you wanted to handle. Below is such an example (and should be avoided in preference to another approach described further below in the writeup) that uses CustomBaseException as the base type of an exception hierarchy and CustomDontWantToCatchException as a type that derives from the base class that you wouldn’t want to catch:
February 5, 2009Feb 5, 200902/5/09
A very common pattern in the usage of managed exception handling is that of catching an exception, inspecting it’s type and rethrowing it once you realize it was not the exception you wanted to handle. Below is such an example (and should be avoided in preference to another approach described further below in the writeup) that uses CustomBaseException as the base type of an exception hierarchy and CustomDontWantToCatchException as a type that derives from the base class that you wouldn’t want to catch:
