Error Handling In VBScript, Part Two

re: Error Handling In VBScript, Part Two

Norman Diamond — Tue, 24 Aug 2004 00:56:00 GMT

> Note that both On Error statements clear the
> recorded error information buffer.

This seems to be a big difference between VBScript and VB. I had developed the style of putting an On Error Goto handler_label before something whose failure I was prepared for, and two On Error Goto 0 statements, one just after the something and one at the beginning of the handler.

But then for one VB application it made sense to have three of these in one function, and after handling and recovering from the first failure, the second failure aborted the function instead of getting sent to its handler. I thought this was a VB bug but I was wrong. Someone taught me that in VB the Resume statement must be executed IN ADDITION TO the On Error Goto 0 statement. The Resume statement told the VB runtime to consider that the function had recovered from the failure (even though the function was still executing in the handler). Then the second failure went to the second failure's handler.

Suppose the program is being done in VBScript instead of VB, and suppose the developer can still anticipate some failures and wants to handle them and continue. On Error Goto 0 is still a fine method of letting unexpected (unhandled) failures propagate upwards. But if VBScript has no On Error Goto some_handler, and no need for a Resume statement, what is the usual method of handling an anticipated exception in VBScript?

re: Error Handling In VBScript, Part Two

Ron — Tue, 24 Aug 2004 12:34:00 GMT

Norman,

The usual method [for VBScript] is by using On Error Resume Next and checking error codes after the statement executes.

As for why the [VB] function didn't raise out of your error handler, once VB's handler is triggered, it's considered to be in handling mode until the function ends or a Resume statement is encountered. If errors are expected in the error handler (and execution should not return back into the function body for the initial error), the handler should first issue a Resume to a label inside the error handler. Then the On Error GoTo 0 will work as expected.

re: Error Handling In VBScript, Part Two

Norman Diamond — Wed, 25 Aug 2004 01:47:00 GMT

8/24/2004 5:34 AM Ron

> The usual method [for VBScript] is by using
> On Error Resume Next and checking error
> codes after the statement executes.

This must make some coding structures even more painful in VBScript than in VB. Thank you for the information though.

> As for why the [VB] function didn't raise
> out of your error handler

Right, I said someone taught me that the Resume statement must be used IN ADDITION TO the On Error Goto 0 statement.

By the way errors were not expected in the error handler (this is the reason I put an On Error Goto 0 at the beginning of the error handler). But the handler Gotoed back to the normal chain of processing, and certain other possible errors were prepared for later (On Error Goto other_handler), but I didn't know at the time that the VB runtime still considered the function to be in handling mode and considered the new error a double fault. So yes I put a Resume in the handler just after the handler's On Error Goto 0. 3 labels and visible gotos per handler.

re: Error Handling In VBScript, Part Two

foxyshadis — Fri, 27 Aug 2004 23:50:00 GMT

Curious about something. Does this mean that Resume Next is actually much slower than catching errors, because it terminates and restarts the interpreter every time? Or does this always happen, or did I just read that wrong?

A side note: Goto sounds like a really messy brand of toy goop. It must be Friday. ^_^

re: Error Handling In VBScript, Part Two

Eric Lippert — Sat, 28 Aug 2004 00:03:00 GMT

First off, why the heck do you care how slow the error handler is? Error conditions are almost never due to something fast, and are frequently followed up by showing an error message to the user. Does it really matter whether it takes 30 ms or 40 ms to put up the "something failed" message box?

Second, no, you're misunderstanding something. The interpreter is just a loop that fetches the next opcode and interprets it. Resume Next saves away error information, moves the instruction pointer forwards to the next beginning-of-statement, and does a goto to the top of the interpreter loop. Restarting the interpreter takes a couple billionths of a second. Saving away the error strings for later is the expensive part. (And that is under some circumstances deferrable, so you don't even incur that cost, but that is a topic for another day.)

Not that it matters, but FWIW, catching errors a la jscript on the other hand is much slower. Searching the call stack for exception handlers, then doing all the cleanup of the various stack frames, branching to the exception handler, and doing all the bookkeeping necessary to maintain integrity in situations where people do stupid things (like put an "eval('return;');" inside a finally -- ouch!) is much more complex and therefore slower than just resetting the instruction counter and continuing merrily along.

re: Error Handling In VBScript, Part Two

Mark — Thu, 02 Sep 2004 19:49:00 GMT

How does IErrorInfo relate to EXCEPINFO? I have used IErrorInfo extensively in ATL COM objects to return error descriptions and source information back to VBScript, which seems to be what the EXCEPINFO structure does too? Are these two ways to do the same thing?

re: Error Handling In VBScript, Part Two

Eric Lippert — Thu, 02 Sep 2004 21:50:00 GMT

The point of IErrorInfo is to provide the information in an EXCEPINFO to objects that are designed to be called on vtable interfaces rather than via IDispatch.

VBScript doesn't use IErrorInfo because VBScirpt never calls via anything but IDispatch. (OK, that's a lie; there is ONE special case which I will blog about at some point where we call IErrorInfo.)

IErrorInfo is clearly the more "COM-like" way to do things. Many problems -- like the ones I mention Spot The Defect Part Two -- could have been avoided had the OLE Automation designers chosen to pass back error information via an interface rather than a struct.

Unfortunately the OLE Automation interfaces were written very early in the history of COM, back when it really wasn't so clear what exactly "COM-like" meant. From a design perspective, lots of OLE Automation is essentially just a thin COM wrapper overtop of a Win32-API-style-hey-let's-pass-some-pointers-to-structs-around model. EXCEPINFO is part of that. Were we to design late-bound dispatch interfaces in COM today, they'd use interfaces like IErrorInfo. But, sadly, we're stuck with two ways to do the same thing.