VB7 Error Handling: So we got try/catch ... so what??

[Tom Barnaby]

I'm seeing a very big deal made about the new try/catch error handling syntax
being introduced in VB7. The applause was deafening when it was introduced
at VBITS with "Never write another On Error Goto".

I have to admit, my reaction was quite different ... it was "So what?"

Since then I thought my reaction was due to my own ignorance. I have been
programming in VB for a relatively short time, and most of that has been
light on error handling. But the other day I read an article which for the
most part mirrored my thoughts, so now I am emboldened enough to post my
take here and get some reaction. As a result, I will likely be shown to
indeed be ignorant. So be it. At least I will have learned something in
the process.

My thinking resolves to this ... yes the On Error/Goto syntax is bad, but
it is not the PRIMARY problem with VB's error handling. VB's limited error
handling is more directly a result of a featureless global error object,
the inability to raise custom error objects, and the lackluster language
support for gathering source code context information at runtime.

The Global Err Object
-----------------------
VB's Err object has 6 properties and 2 methods. This is not even close to
providing the needed functionality. Actually, if the "Source" property did
indeed point directly to the source of the error, it might be ok. But we
are lucky if it gives us the progid of the object that raised the error.
How about a file (full path) and line number? Thats possible in C++ through
a couple easy macros.


Custom Error Objects
---------------------
The fact that the Err object is so limited would not be such a big deal if
we had the capability of raising our own custom error objects. Languages
like C++ and Java can raise any object as an exception. In your try/catch
block you can specifically indicate that you want to "catch" a CMyIO error,
or a CMyDatabase error. These exception objects can be derived from other
exception objects allowing you to leverage the reusability that inheritance
provides and the power of polymorphism.


Gathering Source Code Context
-------------------------------
Erl? Please!! C++ has macros like __LINE__ and __FILE__ that allow you to
grab the line and file name where the error occurred. Used in conjuction
with custom error objects, these macros allow you to point directly to the
source of the problem. Furthermore, the line number is given relative to
the beginning of the file, not the procedure. So, in the IDE, I can hit
Ctrl-G, type the line number in, and go directly to the offending line.
And I don't need to look at the source with a bunch of ugly artificially
added line numbers as is the case with VB line numbering utilities and Erl.


In conclusion, the try/catch syntax is indeed much cleaner than On Error/Goto.
However, the root cause of error handling frustrations in VB goes much deeper
than syntactical ugliness. VB is missing key FEATURES in the area of error
handling. To me, arguing try/catch versus On Error/Goto is much like arguing
the merits of curly braces versus Begin/End. I just don't care ... well
ok, I like curly braces better but thats beside the point ;-).

"Never right another ON ERROR" strikes me as a marketing slogan. All style
and no substance. I hope Microsoft is working on the substantive issues
addressed above, and not just waving the try/catch carrot to distract us
from the core problems.

Thanks for reading! Looking forward to your comments.
Tom

[Miha Markic]

Hi Tom.

I agree with you. I think that try/catch will handle (and VB will allow to
launch custom exceptions) custom exceptions since VB will allow inheritance.

Miha

"Tom Barnaby" <tbarnaby@intertech-inc.com> wrote in message
news:38d03588$1@news.devx.com...
>
>
> I'm seeing a very big deal made about the new try/catch error handling
syntax
> being introduced in VB7. The applause was deafening when it was
introduced
> at VBITS with "Never write another On Error Goto".
>
> I have to admit, my reaction was quite different ... it was "So what?"
>
> Since then I thought my reaction was due to my own ignorance. I have been
> programming in VB for a relatively short time, and most of that has been
> light on error handling. But the other day I read an article which for
the
> most part mirrored my thoughts, so now I am emboldened enough to post my
> take here and get some reaction. As a result, I will likely be shown to
> indeed be ignorant. So be it. At least I will have learned something in
> the process.
>
> My thinking resolves to this ... yes the On Error/Goto syntax is bad, but
> it is not the PRIMARY problem with VB's error handling. VB's limited
error
> handling is more directly a result of a featureless global error object,
> the inability to raise custom error objects, and the lackluster language
> support for gathering source code context information at runtime.
>
> The Global Err Object
> -----------------------
> VB's Err object has 6 properties and 2 methods. This is not even close to
> providing the needed functionality. Actually, if the "Source" property
did
> indeed point directly to the source of the error, it might be ok. But we
> are lucky if it gives us the progid of the object that raised the error.
> How about a file (full path) and line number? Thats possible in C++
through
> a couple easy macros.
>
>
> Custom Error Objects
> ---------------------
> The fact that the Err object is so limited would not be such a big deal if
> we had the capability of raising our own custom error objects. Languages
> like C++ and Java can raise any object as an exception. In your try/catch
> block you can specifically indicate that you want to "catch" a CMyIO
error,
> or a CMyDatabase error. These exception objects can be derived from
other
> exception objects allowing you to leverage the reusability that
inheritance
> provides and the power of polymorphism.
>
>
> Gathering Source Code Context
> -------------------------------
> Erl? Please!! C++ has macros like __LINE__ and __FILE__ that allow you to
> grab the line and file name where the error occurred. Used in conjuction
> with custom error objects, these macros allow you to point directly to the
> source of the problem. Furthermore, the line number is given relative to
> the beginning of the file, not the procedure. So, in the IDE, I can hit
> Ctrl-G, type the line number in, and go directly to the offending line.
> And I don't need to look at the source with a bunch of ugly artificially
> added line numbers as is the case with VB line numbering utilities and
Erl.
>
>
> In conclusion, the try/catch syntax is indeed much cleaner than On
Error/Goto.
> However, the root cause of error handling frustrations in VB goes much
deeper
> than syntactical ugliness. VB is missing key FEATURES in the area of
error
> handling. To me, arguing try/catch versus On Error/Goto is much like
arguing
> the merits of curly braces versus Begin/End. I just don't care ... well
> ok, I like curly braces better but thats beside the point ;-).
>
> "Never right another ON ERROR" strikes me as a marketing slogan. All
style
> and no substance. I hope Microsoft is working on the substantive issues
> addressed above, and not just waving the try/catch carrot to distract us
> from the core problems.
>
> Thanks for reading! Looking forward to your comments.
> Tom
>
>
>
>

[Richard Dalton]

>"Never right another ON ERROR" strikes me as a marketing
>slogan. All style
>and no substance. I hope Microsoft is working on the
>substantive issues
>addressed above, and not just waving the try/catch carrot to >distract us
>from the core problems.


Then is a perfect and concise explaination of the problem with VB. I've
been using it since version 2, and am now officially sick of it.

Great post, no criticism here.

-Richard

[Colin McGuigan]

Tom Barnaby wrote in message <38d03588$1@news.devx.com>...
Kicking this idea around, I had a thunk. In addition to what you proposed
(which are very good points), I'd like to see the global Err object stick
around if events were added to it. You could get an ErrorThrown event (for
when any error is generated, even if it's subsequently caught), an
ErrorRaised event (for when an error is raised, but not caught within the
same procedure), and an UnhandledError event (for when an error isn't
caught, anywhere). Would make things like error logging a whole lot
easier...

--
Colin McGuigan

[Thanassis Stathopoulos]

Colin,
Interesting points you raise here. I got some remarks

It's my understanding that VB Error objects are just thin wrappers
around standard, COM-supplied IErrorInfo implementations.
This is why the Err object is not easy to extend (other than through
an Errors collection like in ADO etc, which essentially wraps
the newer IErrorRecords interface).

If we could replace COM's IErrorInfo with our own implementation, your
request could be easily coded (assuming we are talking real events -
connection points - here and not pseudo-events like class_initialize
and terminate)

The problem with IErrorInfo objects is that they must marshal
themselves by value when going out of process; COM explicitly optimizes
this to save network roundtrips, i.e. any network call will automatically
marshal any errors together with the HRESULTs etc. This should be
true for any "extended" error objects, too.

Your events suggestion might be implemented by introducing custom
hooks into VB's exception handling mechanism- but it would compromise
performance if continuously on (I can't see how the system could track
the "Unhandled Error" and "ErrorRaised" things otherwise).
As such, there should be a "standard class" module
(Application?) in which these "events" were sunk.

Thanassis


Colin McGuigan wrote in message <38d0fdd8@news.devx.com>...
>Tom Barnaby wrote in message <38d03588$1@news.devx.com>...
>Kicking this idea around, I had a thunk. In addition to what you proposed
>(which are very good points), I'd like to see the global Err object stick
>around if events were added to it. You could get an ErrorThrown event (for
>when any error is generated, even if it's subsequently caught), an
>ErrorRaised event (for when an error is raised, but not caught within the
>same procedure), and an UnhandledError event (for when an error isn't
>caught, anywhere). Would make things like error logging a whole lot
>easier...
>
>--
>Colin McGuigan
>
>
>

[Colin McGuigan]

Thanassis Stathopoulos wrote in message <38d137a8@news.devx.com>...
>Colin,
>Interesting points you raise here. I got some remarks
>
>It's my understanding that VB Error objects are just thin wrappers
>around standard, COM-supplied IErrorInfo implementations.
>This is why the Err object is not easy to extend (other than through
>an Errors collection like in ADO etc, which essentially wraps
>the newer IErrorRecords interface).

Hrmm. I'm not sure, but I was under the impression that you just had a
simple object in memory (Err), with a couple of access routines that would
take an HRESULT and map it to something that the Err object could read (or
vice versa). Either way, extending the object with new properties, etc, is
pretty much useless/not doable.

>If we could replace COM's IErrorInfo with our own implementation, your
>request could be easily coded (assuming we are talking real events -
>connection points - here and not pseudo-events like class_initialize
>and terminate)

I honestly can't see any reason why it wouldn't be possible either way;
although real events would be more flexible, they'd also be slower; it might
be implemented as a callback for speed, which might help on the performance
issue; pass it a function in a module (or perhaps a static function from a
class).

>The problem with IErrorInfo objects is that they must marshal
>themselves by value when going out of process; COM explicitly optimizes
>this to save network roundtrips, i.e. any network call will automatically
>marshal any errors together with the HRESULTs etc. This should be
>true for any "extended" error objects, too.

Hrmm. I wasn't really thinking of extending the error object, but being in
more of a position to respond to it when certain things happen. Looking at
it, I guess you could have some sort of included interface that could be
implemented so that VB could handle the marshalling, et al, for you as long
as you provided some standard services (serialization for performance,
etc)...but I don't think it's likely.

>Your events suggestion might be implemented by introducing custom
>hooks into VB's exception handling mechanism- but it would compromise
>performance if continuously on (I can't see how the system could track
>the "Unhandled Error" and "ErrorRaised" things otherwise).
>As such, there should be a "standard class" module
>(Application?) in which these "events" were sunk.

Well, it would compromise performance, because it's doing something new, but
that impact might be negligible. Obviously, VB knows when you have an
unhandled error: it displays the msgbox and then craps out. Similarly, it
should know when you've called the Err.Raise method. Specifying between an
error that's been raised within the procedure and within another procedure
might be problematic, but if the Source property gets improved, it could be
doable.

>Thanassis


Not like I think any of this will happen. Just thought it'd be neat. =P

--
Colin McGuigan

[Tom Barnaby]

"Miha Markic" <miham@spin.si> wrote:
>Hi Tom.
>
>I agree with you. I think that try/catch will handle (and VB will allow
to
>launch custom exceptions) custom exceptions since VB will allow inheritance.
>
>Miha
>

Miha,

I hope you are right about custom exceptions, but I am not so sure. Based
on the limited VB7 examples available I have seen no indication that these
are going to be offered. When I see some preliminary code like the following,
then I will applaud ...

Try
DoSomething()
Catch MyIOError
HandleIOError()
Catch MyDatabaseError
HandleDBError()

[Tom Barnaby]

"Colin McGuigan" <colin@chicor.com> wrote:

I like it!

>Kicking this idea around, I had a thunk. In addition to what you proposed
>(which are very good points), I'd like to see the global Err object stick
>around if events were added to it. You could get an ErrorThrown event (for
>when any error is generated, even if it's subsequently caught), an
>ErrorRaised event (for when an error is raised, but not caught within the
>same procedure), and an UnhandledError event (for when an error isn't
>caught, anywhere). Would make things like error logging a whole lot
>easier...
>
>--
>Colin McGuigan
>
>
>