*/
Got something to write about? Check out our Article Builder.

Other Views

corner
*/

C# School - Exception Handling - Lesson #9 - Page 1

                     Next Page



Exception Handling in C#

If you are new to the C# School
This is the 9th in the series of lessons of our C# School. The C# School is a kind of interactive learning platform where those who want to learn .NET with C# can find help and support. With one issue a week, describing some areas of the C# Programming Language with the Microsoft .Net Platform, this is not the same traditional passive tutorial where the author only writes and the reader only reads. There will be exercise problems at the end of each issue, which the reader is expected to solve after reading the issue. The solution to these problems will be provided in the next issue for testing purposes. There is also a dedicated message board attached with the school, where you can ask questions about the article, and the author will respond to your question within 2/3 days. You can send your suggestions, feedback or ideas on how these lessons can be improved to either the Author ( farazrasheed@acm.org)or the WEBMASTER ( info@programmersheaven.com).

For previous lessons: Lesson Plan
Today we will explore exception handling mechanisms in C#. We will start out by looking at the idea behind exceptions and will see how different exceptions are caught. Later, we will explore different features provided and constraints applied by the C# compiler in exception handling. Finally, we will learn how to define our own custom exceptions.

Exceptions Basics
Put simply, exception handling is a mechanism to handle run-time errors in .NET that would otherwise cause your software to terminate prematurely.

The need for Exceptions
Consider the following simple code:

using System;
namespace CSharpSchool
{
	class Test
	{
		static void Main()
		{
			double p = Divide(3, 5);
			Console.WriteLine(p);
		}
		static double Divide(double a, double b)
		{
			double c = a/b;
			return c;
		}
	}
}


The Divide() method returns the result of the division of the two numbers passed as parameters. The output of the program will be:

0.6

But what if the method Divide() is called in the Main() method as

	double p = Divide(3, 0);


There will be no compile time error as both the parameters are cast-able to double. But when the program is executed, the computer will attempt to divide 3 by zero which is not possible. As a result, the program will crash! One way to deal with this is to explicitly check the second parameter and if it is zero return some value to indicate the error

	static double Divide(double a, double b)
	{
		if(d == 0)
		{
			return 0;
		}
		double c = a/b;
		return c;
	}


The calling code will be:

	static void Main()
	{
		double p = Divide(3, 5);
		if(p == 0)
			Console.WriteLine("Error in input");
		else
			Console.WriteLine(p);
	}


Here we return a value 'zero' to indicate an error in the input. But the problem is that zero can itself be the result of some division like (0 divided by 4) and in this case the caller may get confused whether the returned value is an error or is a legal result, e.g.

	static void Main()
	{
		double p = Divide(0, 3);
		if(p == 0)
			Console.WriteLine("Error in input");
		else
			Console.WriteLine(p);
	}


In this case the program will display that there is an error in the input, which is clearly not the case. So how do we solve this problem?

Exceptions in C# and .Net
People have worked on this problem and developed a solution in the form of 'Exceptions'. Programmers may define and throw an exception in the case of unexpected events. Below are some important points about exceptions and exception handling mechanisms in C# and .Net
  • All exceptions in .Net are objects.
  • The System.Exception class is the base class for all exceptions in .Net.
  • Any method can raise or throw an exception in the case of some unexpected event during its execution using the throw keyword in C#.
  • The thrown exception can be caught or dealt within the calling method using the try...catch block.
  • The code that may throw an exception which we want to handle is put in the try block. This is called an attempt to catch an exception.
  • The code to handle the thrown exception is placed in the catch block just after the try block. This is called catching the exception. We can define which particular class of exception we want to deal in this catch block by mentioning the name of exception after the catch keyword
  • Multiple catch blocks can be defined for a single try block where each catch block will catch a particular class of exception.
  • The code that must always be executed after the try or try...catch block is placed in the finally block, placed just after the try or try...catch blocks. This code is guaranteed to always be executed whether the exception occurs or not.
  • When an exception is raised during the execution of the code inside the try block, the remaining code in the try block is neglected and the control of execution is transferred to the respective catch or finally block.
  • Since exceptions are present in .Net as classes and objects, they follow the inheritance hierarchy. This means that if you write a catch block to handle a base class exception, it will automatically handle all of its sub-class's exceptions. Attempting to catch any of the sub-class's exceptions explicitly after the parent class exception will cause a compile time error.
  • The finally block is optional. Exception handling requires a combination of either the try...catch, try...catch...finally or try...finally blocks.
  • If you do not catch an exception, the runtime environment (Common Language Runtime or CLR) will catch it on your behalf, causing your program to terminate.
Author's Note: For Java developers, there is no concept of checked exceptions in C#. All the exceptions are implicitly unchecked. Hence, there is no 'throws' keyword present in C#. The absence of checked exceptions in C# is quite a hot topic of debate since the birth of C#. I personally feel that the idea of checked exceptions is extremely good and it should have been there in C# or in any strongly typed language. See the Microsoft site for the argument of Hejlsberg and other designers of C# for why they haven't included checked exceptions in C#. http://msdn.microsoft.com/chats/vstudio/vstudio_032103.asp


                     Next Page



corner
© 1996-2008 CommunityHeaven LLC. All rights reserved. Reproduction in whole or in part, in any form or medium without express written permission is prohibited.
Violators of this policy may be subject to legal action. Please read our Terms Of Use and Privacy Statement for more information.
North American business development: Nicolai Wadstrom. Publisher: Lars Hagelin.