Theory
The crash you have met before
Cashier types the price "12x", ShopKeeper runs CDec(txtPrice.Text), and .NET raises an exception; unhandled, the app dies mid-queue.
You know this story: BookBridge died the same way in BCA403 until try/catch arrived. The Java grammar transfers here almost word for word.
But VB.NET carries something Java never had: a second, older way of handling errors, inherited from classic VB6. The syllabus wants you fluent in the new and able to READ the old, because the old still lurks in real shop software.
Theory
Structured handling: the modern school
Structured exception handling is Try/Catch/Finally, block-scoped and typed:
- risky lines go in Try
- each Catch names the exception type it handles, specific first, general last (child before parent, the BCA403 ordering rule unchanged)
- Finally runs on every exit: success, failure, even a Return
- Throw raises an exception; ex.Message describes one
The words are Java's with End Try instead of braces; every trace you practised in BookBridge (the A-C-D jump) replays identically.
Practical
Both schools, same bad price
' STRUCTURED: the modern standard
Private Sub btnAdd_Click(sender As Object, e As EventArgs) _
Handles btnAdd.Click
Try
Dim price As Decimal = CDec(txtPrice.Text) ' "12x" throws here
lblStatus.Text = "Added at " & price
Catch ex As InvalidCastException
errProv.SetError(txtPrice, "Price must be a number")
Catch ex As Exception ' general net, LAST
MessageBox.Show("Unexpected: " & ex.Message)
Finally
txtPrice.SelectAll() ' runs either way
End Try
End Sub
' UNSTRUCTURED: legacy VB6 style, read-only knowledge
Sub OldSchoolAdd()
On Error GoTo Handler
Dim price As Decimal = CDec("12x") ' jumps to Handler on failure
Exit Sub
Handler:
MsgBox("Error " & Err.Number & ": " & Err.Description)
End Sub
Theory
Unstructured handling: the old school
Before .NET, VB errors were handled procedure-wide:
- On Error GoTo label: from that line on, ANY error in the procedure jumps to the label
- Resume Next (inside a handler): go back and continue after the failing line
- Err object: Err.Number and Err.Description describe the latest error
- On Error Resume Next: the infamous one: every error is silently skipped, the procedure marches on with whatever half-done state remains
One hard rule: a procedure cannot mix the 2 styles; Try and On Error in the same Sub is a compile error.
At a glance
Structured vs unstructured (the exam table)
| Aspect | Structured (Try/Catch) | Unstructured (On Error) |
|---|---|---|
| Scope | Exact block you wrap | Whole procedure after the On Error line |
| Error identity | Typed exception objects (ex As FormatException) | One Err object, numbers for kinds |
| Cleanup | Finally, guaranteed | Manual, easy to miss |
| Readability | Handling sits beside the risk | GoTo jumps to distant labels |
| Status | The .NET standard | Legacy VB6 compatibility |
Quiz
A procedure starts with On Error Resume Next. Halfway down, CDec("12x") fails. What does the program do?
- Shows the default error dialog and stops the procedure
- Skips the failing line silently and continues with the next statement
- Jumps back to the procedure's first line and retries
- Converts the text to 12, ignoring the invalid characters
Show the answer
Skips the failing line silently and continues with the next statement
Resume Next as a policy means every error is swallowed: the assignment simply does not happen, price keeps its previous value (0 for a fresh Decimal), and the procedure strolls onward, wrong numbers and all: bills that are silently zero. That silence is why the construct is infamous, and why option A is wrong: suppressing that dialog is precisely what it does. Option C invents a retry loop. Option D describes Val()'s forgiving parse, a different tool entirely: error HANDLING never edits your data.
Think first
Translate your Java reflexes
From BCA403 you know: try, catch child-before-parent, finally always runs, e.getMessage(). Before tapping, write each one's VB.NET spelling.
Show the answer
try becomes Try ... End Try; catch (FormatException e) becomes Catch ex As FormatException, and the ordering rule survives intact: specific Catch above the general Catch ex As Exception, or the general one swallows everything first. finally is Finally, same guarantee, same runs-even-on-Return behaviour. e.getMessage() is ex.Message: a property now, no brackets. One import of knowledge, zero new concepts: the fourth language in your BCA to use this exact machinery, which is rather the point of learning machinery.
Watch out
Where marks and bills go missing
On Error Resume Next in new code: the silent-zero bill from the quiz; in an exam, name it as the dangerous option and say why: errors are IGNORED, not handled.
General Catch first: Catch ex As Exception above the specific ones makes them unreachable: same compile-time complaint Java gave.
Mixing schools: Try and On Error in one procedure does not compile; pick one (pick Try).
Theory
Unit 3 closes; the till is trustworthy
Error handling was the last brick: ShopKeeper's face (controls, containers, grid), its tray workers, its menus and dialogs, and now its composure when input goes wrong: ErrorProvider for the expected mistakes, Try/Catch for the rest, Finally for cleanup. Unit 4 changes register completely: the Item and Bill CLASSES behind this screen, VB.NET's OOP: Me and MyBase where Java said this and super. Your BCA403 muscle memory is about to pay for the whole unit.
Summary
Key takeaways
- Structured: Try / typed Catch blocks (specific first) / Finally (always runs) / End Try; Throw raises, ex.Message describes.
- Unstructured (legacy): On Error GoTo label, Resume Next, the Err object (Number, Description).
- On Error Resume Next silently skips every error: name it as dangerous, never write it in new code.
- One procedure cannot mix the 2 styles.
- Structured wins on scope, typing, guaranteed cleanup and readability: the exam comparison table.
- Java translation: try=Try, catch=Catch ex As Type, finally=Finally, getMessage()=ex.Message.
- Memory hook: Try handles, Resume Next hides.