Can't tell if you're joking or not, but this is hilarious regardless.
I believe a more serious answer would be: You could easily trap the error number and make it pop up in a MsgBox, then decide what to do with each type of error. Complex objects or functions would often each need their own custom error handling code, but it wasn't hard to do.
Not hard to do, just hard to do well. You have On Error GoTo and On Error Resume Next. There is no indication that any particular statement will have an error. Even if it is obviously something that could error, you don't necessarily know what kind of error.
The evidence shows that most writers of VB apps neither predicted errors nor found these error situations in testing.
The MsgBox is there purely for debugging purposes, you take that line out before the software is put in front of users. A single object or function can generate multiple error numbers at different points & in different situations-- ideally you trap and handle them all (in varying ways depending on the type of error) during the debugging phase.
I once saw a function in VB that had "ON ERROR RESUME NEXT" as the first statement and the code didn't look quite right. After removing on-error-resume-next, every line of the function threw an error. Someone had cut and pasted some code from a book on Access 97.
You do end up with some interesting approaches to error handling with that, e.g. from a sprite editor[0] i wrote a few years ago in VB5 (later ported to VB6) for fun:
Private Sub cmdOk_Click()
On Error Resume Next
WInt = 0
HInt = 0
WInt = CInt(txtWidth.Text)
HInt = CInt(txtHeight.Text)
If CStr(WInt) <> txtWidth.Text Or CStr(HInt) <> txtHeight.Text Then
MsgBox "Invalid numeric values for the dimensions"
txtWidth.SetFocus
Exit Sub
End If
Tag = vbOK
Hide
End Sub
This basically asks for a width and height but the entry boxes are text so anything could be entered there. CInt tries to convert text to integer and if that fails it errors out. With 'On Error Resume Next' it moves on to the next if that fails instead of producing an error and WInt or HInt would remain whatever it was. Since they're initialized to 0 there are always some valid integers in there. CStr would convert the integer to string (0 if the string-to-integer failed) so that the assumption is that if the strings converted to integers and then converted back to strings weren't the same as the original strings there were some invalid characters in there.
(in hindsight i should have also checked for negatives values but eh whatever)
Really? All you need is On Error Resume Next . Dead simple.