3 ms·
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 mak
by slfnflctd 4y ago
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.
- skeeter2020 4y ago> 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
- slfnflctd 4y agoThe 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.
- projektfu 4y agoNot 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.
- gamblor956 4y agoNot 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?
- ptx 4y agoYes, but without stacktraces, so all you get is an error code. Good luck debugging.