Sams Teach Yourself .Net in 21 Days
- Table of Contents
- Copyright
- About the Author
- About the Technical Editor
- Acknowledgments
- We Want to Hear from You
- Introduction
- Week 1: At a Glance
- Day 1. Introduction to the Microsoft .NET Framework
- Day 2. Introduction to Visual Studio .NET
- Day 3. Writing Windows Forms Applications
- Day 4. Deploying Windows Forms Applications
- Day 5. Writing ASP.NET Applications
- Day 6. Deploying ASP.NET Applications
- Day 7. Exceptions, Debugging, and Tracing
- Why Errors Happen
- Understanding Exceptions in .NET
- Using Structured Exception Handling
- Using Visual Studio .NET to Debug Applications
- Summary
- Q&A
- Quiz
- Exercises
- Week 1. In Review
- Week 2: At a Glance
- Day 8. Core Language Concepts in Visual Basic .NET and C#
- Day 9. Using Namespaces in .NET
- Day 10. Accessing Data with ADO.NET
- Day 11. Understanding Visual Database Tools
- Day 12. Accessing XML in .NET
- Day 13. XML Web Services in .NET
- Day 14. Components and .NET
- Week 2. In Review
- Week 3: At a Glance
- Day 15. Writing International Applications
- Day 16. Using Macros in Visual Studio .NET
- Day 17. Automating Visual Studio .NET
- Day 18. Using Crystal Reports
- Day 19. Understanding Microsoft Application Center Test
- Day 20. Using Visual SourceSafe
- Day 21. Object Role Modeling with Visio
- Week 3. In Review
Understanding Exceptions in .NET
When an error occurs in a Visual Basic 6.0 application, the Err object fills with information about the last error that occurred. Your application is then thrown that error information, and the error is handled by the On Error code you wrote. In Visual Basic .NET, the Err object still exists, but for backward compatibility only. In C#, the Err object doesn't exist. To make your code compliant with the Common Language Specification (CLS), you must use the exception object from the System.Exception class in the Framework Class Library (FCL).
The Exception object contains the information you need about the last error that occurred in your application. When an error occurs, an Exception object is created. So, when a block of code causes an error, an exception is thrown and the first block of code in the stack that has an exception handler takes care of that exception. If there's no exception-handling code, a runtime error occurs, and your application terminates. Table 7.1 lists the properties of the Exception object.
Table 7.1. Properties and Descriptions of the Exception Object
|
Property Name |
Property Description |
|
HelpLink |
Gets or sets the help file associated with the application |
|
InnerException |
Gets a reference to the inner exception |
|
Message |
Gets a string representing the error message associated with the exception |
|
Source |
Gets or sets the name of the application object that caused the exception |
|
StackTrace |
Gets the stack trace identifying the location in the code where the exception occurred |
|
TargetSite |
Gets the method name where the exception occurred |
Using the properties of the Exception object, you can determine what to do about the exception that occurred. This might be notifying the user with a MessageBox prompt or handling the error and continuing execution in your code.
Now that you understand what an exception is, you need to learn how to handle them in code. In .NET, you use structured exception handling (SEH) to help you handle errors in code.
Using Structured Exception Handling | Next Section

Account Sign In
View your cart