Hacker News Reader

Comment by zozbot234 | Hacker News Reader

> Error handling was terrible in VB

Really? All you need is On Error Resume Next . Dead simple.

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.

> You could easily trap the error number and make it pop up in a MsgBox

What would a non-developer do after seeing an error number? Click OK and carry on? Might as well just resume next

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.

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.

Not hard to do, just hard to do well.

The evidence shows that most writers of VB apps neither predicted errors nor found these error situations in testing.

So exactly like the current Javascript ecosystem then?

Yes, but without stacktraces, so all you get is an error code. Good luck debugging.

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)

[0] http://runtimelegend.com/tools/mseditor/

“How did you say YOLO in the 90s?”

Reply on news.ycombinator.com