4.1.1.9 - Exceptions and defensive input (VB.NET)
Learn how exceptions change control flow, handle expected failures precisely and validate input so a program can recover without using invalid data. This native written-code route is incomplete: runnable support pending.
Exceptional conditions and control flow
An exception signals that an operation could not complete normally; it interrupts the current sequence and transfers control to a matching handler. A conversion may fail even though the source code is syntactically valid.
Exception handling
Responding to a signalled runtime failure through a handler, rather than allowing the normal sequence to continue as though the operation succeeded.
Integer.Parse("six") throws a FormatException because the text is not a valid integer. Parsing an integer outside the supported range throws an OverflowException. Accessing an array outside its valid bounds can throw IndexOutOfRangeException; integer division by zero throws DivideByZeroException. The failure's type helps identify what went wrong. Do not assume every questionable arithmetic operation throws: floating-point division has different behaviours from integer division.
Distinguish these from a syntax error, which prevents valid translation, and a logic error, which lets the program execute but produces the wrong result. Calculating a delivery fee with the wrong rate can be a logic error without any exception. Handling exceptions therefore does not prove a solution is correct.
When an exception is thrown, statements after the failing operation in that Try are skipped. A handler receives control if its Catch type matches the exception. If no appropriate handler is found, the failure propagates to callers and may end the program. It does not silently invent a valid replacement value. Catching an exception without deciding what to do with the affected data can hide a fault.
Handling and reporting conversion errors
A Try...Catch structure protects an operation whose expected failures the program can handle; the catch block should state a useful recovery action or explanation. Keep the protected operation narrow enough to understand which failures it is designed to catch.
Dim inputText As String = "large"
Try
Dim quantity As Integer = Integer.Parse(inputText)
Console.WriteLine(quantity * 2)
Catch ex As FormatException
Console.WriteLine("Enter a whole number.")
Catch ex As OverflowException
Console.WriteLine("The number is outside the supported range.")
Finally
Console.WriteLine("Conversion attempt complete.")
End Try
Console.WriteLine("Ready")
For the given text, the output is Enter a whole number., then Conversion attempt complete., then Ready. The multiplication is skipped. With inputText = "12", output is 24, then the completion message and Ready; neither Catch executes. The code can also report overflow from the protected integer calculation, so the message describes a supported range rather than pretending every overflow came from parsing.
Catch blocks are checked in order; place specific exception types before a broader Catch ex As Exception, or the broad handler can absorb failures intended for a later handler. Catching every exception is rarely a good way to validate ordinary input: it can conceal programming defects unrelated to the input.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account