Conclusion

Handling exceptions is a key part of any program, since programs must be equipped to deal with failure and unexpected situations. It is important not to neglect exception handling when you are writing a program! This chapter finishes the coverage of what goes on within methods ; in our next chapter, we'll start discussing types by talking about modules, the simplest kind of user -defined type, as well as how types are organized.

Here are some style points to consider.

• Exceptions should never just be ignored. Catching an exception and doing nothing but throwing away the exception is a very bad practice that is prone to causing serious bugs . Properly handling exceptions in a program is fundamental to proper execution of a program.

• Because looking for an exception handler incurs a fair amount of overhead (even if the exception handler is in the same method where the exception was thrown), exceptions should only be thrown in truly exceptional situations. Exceptions should not be used in place of returning a value from a function, for example, or communicating some value between two methods through reference parameters.

• Exceptions can also be thrown using the Error statement. The Error statement takes an error number as an argument instead of an exception object. This is a holdover from previous versions of the Visual Basic language, where exceptions were thrown by number instead of by type. In Visual Basic .NET, the error number is translated into the appropriate exception type, and then a new exception of that type is thrown. Use of the Error statement is strongly discouraged.

• Structured exception handling involves less overhead and is more precise than unstructured exception handling. Although there are no major technical disadvantages to using unstructured exception handling, the Try...Catch style of error handling is encouraged over On Error .