Fog Creek Software
Discussion Board




Catching all uncaught exception in Visual Basic

In Unix C, it is done via "signal"?

In Java, we put a big try-catch-finally structure against everything and exception will propagate to the top most function.

But I have not seen any sample code done in VB6 yet.  Is it possible?

Amour Tan
Thursday, August 15, 2002

Amour,

http://peach.ease.lsoft.com/scripts/wa.exe?A0=visbas-l might be a more appropriate place to ask this question.

Matthew

Matthew Wills
Thursday, August 15, 2002

Matthew,

I think this question is relevant here because CityDesk (a product frequently discussed here and written in VB) has this feature, take a look at:

http://www.joelonsoftware.com/articles/fog0000000009.html

I just could not figure out how it is done.

Amour Tan
Thursday, August 15, 2002

I've never used VB ... but a minute with Google found this, which might be relevent:

http://www.keysound.com/html/error_faq.htm

Apparently, VB.NET support Try/Catch/End Try.

name witheld by request
Thursday, August 15, 2002

Nope, the link ask you to put error handling codes in all events and functions.  This is too manual and error prone.

What CityDesk has is it "catches any unhandled exception" as quoted from the page.

Joel,

you want to share with us how you do it?

Amour Tan
Thursday, August 15, 2002

Seems like you're looking for a cheap way out.

Are you thinking of exceptions that you can't predict and thus not take any precautions for? I wonder if those really exist... Can you give an example?

I would think it would be better to catch any errors when they occur and handle them in an alternative flow, gracefully. That way you stay in control.

Erik van Linstee
Friday, August 16, 2002

"Michael added a dialog box to CityDesk for sending feedback. He also wrote some very spiffy code that catches any unhandled exception on any copy of CityDesk...."

I know that CityDesk was written in VB, and C++ for some parts that needed performance or low-level control. I take it this exception handling routine is written in C++ and linked to work with the VB code.

Patrik
Friday, August 16, 2002

Erik van Linstee wrote:
"Are you thinking of exceptions that you can't predict and thus not take any precautions for? I wonder if those really exist..."

If you can predict all exceptions that might occur, you must be making a fortune.

Jan Derk
Friday, August 16, 2002

"Are you thinking of exceptions that you can't predict and thus not take any precautions for? I wonder if those really exist..."

A java programmer can simply catch objects of type Throwable, if she wants to get all exceptions.  I hope this gives insight into this question; I don't know what VB/C++ people do.

anon
Friday, August 16, 2002

"If you can predict all exceptions that might occur, you must be making a fortune."

Well, I am, but not because of that :-)

But seriously, no, of course I can't predict all exceptions that might occur in one application, or even module. But what I can do is consider everything that might go wrong with each line I write, line by line. As long as you do that, you have a lot less to worry about, and what remains is typically beyond your control anyway.

Each line of code has well known intended effects, and is bound to have some not intended, but nevertheless well known side effects. To explain what I mean, look at creating an object. If all goes well, the object exists after creation, or else it won't. If you check if the creation was succesful, you should have no worries later on, so you might decide not to check later if the object that you got passed. Your in trouble if it doesn't and you might think you need exception handling. Actually, you do, but why leave it up to the compiler?

I know this is just one situation, but as long as you carefully consider each situation, you vastly reduce the number of unexplained exceptions further on.

I know this also does not account for parts of the software that you did not write and have no control over, but it is always a good idea to encapsulate them anyway, giving you ample oppertunity to catch the crooks before they can get to your goodies.

There is a lyric by a well known British band that explains how you can't change the world, but you can change the facts, and when you change the facts, and when you change the facts, you change points of view. If you change points of view you may change a vote, and when you  change a vote, you may change the world.
In the same vain, you can't comprehend all the exceptions of a single app, but you can comprehend the consequences of each single instruction.

Laborious, tedious? Maybe, but who said programming was easy. That's why they need us high paid professionals, right?

By the way, I am open to good counter examples, and I might even change my mind. So don't be shy :-)

Also, I realise I am not as eloquent as, say, Edsger Dijkstra - whose argument against the Goto instruction applies to this as you might realise - seeing as how I am not a native speaker, but I hope most of my point is clear enough for anyone to attack it thoroughly :-)

Erik van Linstee
Friday, August 16, 2002

"A java programmer can simply catch objects of type Throwable, if she wants to get all exceptions. I hope this gives insight into this question; I don't know what VB/C++ people do."

Once you start throwing things you are bound to need a catcher, but what if you could suppress the urge to throw and carefully give instead?

Isn't a throw simply a Goto in another form? If not, what is different? If it is, why is a Goto such a despised instruction, and how is the throw so noble?

BTW, I am not a programmer - I used to be, ages ago, but have moved on to other areas of development - so I might simply be showing off my lack of contemporary facts. Still, I am seriously interested in the answers to the questions I pose, and I am definitely not pulling any of your collective legs...

Erik van Linstee
Friday, August 16, 2002

One word: "SetUnhandledExceptionFilter".

John C
Friday, August 16, 2002

I think the problem here is the definition of "exception".  Visual Basic implements "not very structured" exception handling via the semi-obselete On Error Goto _label_ / Resume [Next][label] syntax.  There is also the Windows structured exceptions which can occur in a VB program if you use API functions incorrectly, or a 3rd party library has a bug in it; the most common one (in my experience) is "Access Violation".  I would guess that Joel was talking about the latter type of exception.  As was just mentioned, the way to deal with this is to set a VB procedure as a Windows Exception handler:

http://www.devx.com/premier/mgznarch/vbpj/1999/05may99/bb0599.pdf

As for handling the former type of exception globally, I don't think that there is any way of doing this.  However, if you put error trapping on all event procedures on each top level form, and delegate to a central error handler, you have got some means of control.  Sadly, using an error trapped Sub Main, and providing a DoEvents loop after loading the initial form does not work, although it ought to, if you look at the stack!

Mark Alexander Bertenshaw
Friday, August 16, 2002

John C is one the right track.  Look up the documentation for the Win32 API function, SetUnhandledExceptionFilter.

This should allow you to create a routine that will get called whenever an unhandled error occurs.

Rick
Friday, August 16, 2002

Erik, goto is a construct that bad programmers can really run amok with.  It's just such a raw powerful construct in von Neumann machines, that it needs its powers to be partitioned by special syntax.  So instead of using goto's for loops, errer handling, and code jumping, you use for/while, exceptions, and functions.

At least in C-style languages, this is the reason. ;)

And while you can conceivably keep in mind all that can go wrong with your code, why not have computer keep track of this?  Whenever you make an add that can overflow, or a raft of other things, the computer can aid you.

anon
Friday, August 16, 2002

<quote>
Nope, the link ask you to put error handling codes in all events and functions. This is too manual and error prone.

What CityDesk has is it "catches any unhandled exception" as quoted from the page.
</quote>

You simply can't do that in VB (not in 'pure' VB anyway). The link (to keysound.com) is the best way to do it in VB. If you want to discuss the issue further, http://peach.ease.lsoft.com/scripts/wa.exe?A0=visbas-l may be some assistance.

Seeya
Matthew

Matthew Wills
Sunday, August 18, 2002

Anon,

I appreciate your explanation, but I know quite well the ins and outs of the various constructs, including the Goto. My question was not to get that explained, but to find an explanation why people seem to think that Goto's are generally bad, while they think the use of error trapping is oke. When in fact it is hardly any different from a Goto in many cases.

My argument is to avoid it whenever you can and process the result of your actions yourself. I know there are situations where you cannot avoid it, especially if the programming language, or the API, that you use makle you.

But, although there are many things that can go wrong, there is usually only one expected result. So no matter how many wrong results, as long as you check for getting the right result and acting upon that if you do not, you never have to anticipated every single wrong result and what might cause it. If you keep that in mind, at least that part of programming need not be very complex.

If you count on the computer to trap exceptions, instead of checking for them yourself, you give control away when I don't think you want to. Because when you do, you also have no control over what happens next, even if you have an exception handler. Because then you have to deduce from very limited information what went wrong and what to do next. This is fine for catching programming bugs and exiting your app gracefully, but your first concern is error recovery.

Erik van Linstee
Monday, August 19, 2002

Sorry for the underestimation, Erik. ;)

From what I hear, C++ exceptions are roundly condemned.  Those of us from non-C++ backgrounds occasionally don't realize that they're putting their feet in their mouths when talking about exceptions.  Maybe a C++ exception is a glorified goto.

anon
Monday, August 19, 2002

Well, we have gone way of the original topic anyway, which was catching uncaught exceptions in VB.

If that is for the purpose of exiting gracefully in the face of a bug in error recovery, that's fine. But, if it is to cut corners on building error recovery code in the proper places (where the error might occur), I think one is in for trouble.

Anyway, enough on the subject, I suppose...

Erik van Linstee
Monday, August 19, 2002

I don't believe it's accurate to say that C++ exceptions are "roundly condemned". Actually, it was the C+ community itself that became aware of the weaknesses "its" exception handling mechanism had, and brought those to light - I first heard about it in the now-defunct "C++ Report". I do agree that there's still discussion about how to best put these "darn things" to use :)

However, there's no point in arguing whether exception handling (or goto or whatever) is "bad for you". It's just another tool. If it simplifies your life, go ahead and use it. If it comes back to bite your behind later on, well, that's the way it goes. You make your choices, and you pay the price.

I use both exception handling and goto, each for its goal. I can't "goto" my way out of a method, and if I could, my guess it that it wouldn't get my objects and smart pointers properly destroyed. That's where exceptions come in handy.

Just an opinion.

Paulo Caetano
Monday, August 19, 2002

Man, using goto in c++. Whatever next...

John C
Monday, August 19, 2002

I never understood why all the commotion about 4-letter words :)))))

Anyway, what's the difference between a goto in C++ and a goto in Basic, or in Cobol, for that matter?

Paulo Caetano
Tuesday, August 20, 2002

*  Recent Topics

*  Fog Creek Home