Error Detection and Error Handling VB.NET

Let us begin by clarifying some terminology. We agree to say that handling an error means responding to a detected error. Thus, there is a clear distinction between error detecting and error handling. The reason for this distinction is that these processes can take place at different times and in different locations within the code of an application. We also agree to refer to the procedure (or module) in which an error occurs as the offending procedure (or module).

There are two types of errors that can occur in a running program. (We will not discuss compile-time orsyntax errors.) A runtime error occurs when Visual Basic attempts to perform an operation that is impossible to perform, such as opening a file that does not exist or dividing by 0. Visual Basic automatically takes care of error detection for runtime errors because it has no other choice. On the other hand, proper error handling of runtime errors is up to the programmer, for otherwise Visual Basic itself handles the error by presenting an error message and terminating the application, which is not a good solution to the problem.

A logical error is often defined as the production of an unexpected result. It might be better to define it as the production of an unexpected and incorrect result (although even this is still somewhat ambiguous). For instance, consider a function that returns the IQ for an individual based on a set of IQ test scores. If the individual is very smart, we might expect an IQ in the range of 120 or more. A result of 100 might be unexpected, but it is not necessarily an error. On the other hand, if the function returns an IQ of -350, that is a logical error.

Visual Basic (or, for that matter, any other language) does not provide error detection for logical errors, because to Visual Basic, no error has occurred. However, a logical error may subsequently result in a runtime error, which Visual Basic will certainly recognize. For instance, code that is intended to retrieve a positive integer for later use in an integer variable may instead retrieve 0. This is a logical error. But if that integer is later used as a denominator in some other part of the application, we can surely expect a runtime error.

Thus, it is up to the programmer to anticipate logical errors and provide both error detection and error handling. From this perspective, logical errors are far more serious and much more difficult to deal with than runtime errors. After all, a runtime error won't be completely overlooked-at least Visual Basic will do something about it, even if that consists only of presenting an error message to the user and terminating the application.

The problem with an overlooked logical error is that it may give the user specious information (that is, invalid information that looks valid). This is no doubt the most insidious behavior a program can produce. If we are lucky, a logical error will generate a runtime error at some later time, but we may still have great difficulty determining the location of the logical error from the runtime error message.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

VB.NET Topics