| Groups | Blog | Home |
dotnet web services : App wide catchall exception handler
On Mar 27, 5:06 am, "John" <i...@nospam.infovis.co.uk> wrote: > Hi > > I have a vs2008 winform app that has a start-up form assigned through > application framework i.e. no Sub Main. How can I setup a catchall exception > handler to my app to catch any unexpected exceptions? > > Thanks > > Regards
Hi
I have a vs2008 winform app that has a start-up form assigned through application framework i.e. no Sub Main. How can I setup a catchall exception handler to my app to catch any unexpected exceptions? Thanks Regards
In "Projects properties", select the "Application" tab and the "View
Application Events" button. It will create a vb file that allows to handle Application level events including an "UnhandledException" event... "John" <info@nospam.infovis.co.uk> a écrit dans le message de news: uU$ZUe7jIHA.536@TK2MSFTNGP06.phx.gbl... [quoted text, click to view] > Hi > > I have a vs2008 winform app that has a start-up form assigned through > application framework i.e. no Sub Main. How can I setup a catchall > exception handler to my app to catch any unexpected exceptions? > > Thanks > > Regards > >
[quoted text, click to view]
John wrote: > I have a vs2008 winform app that has a start-up form assigned through > application framework i.e. no Sub Main. Why not? I haven't played with the Application Framework yet and, personally, I /like/ Sub Main. [quoted text, click to view] > How can I setup a catchall exception handler to my app to catch > any unexpected exceptions? Apart from the occasional left-field stuff that the Framework throws at you, you shouldn't /have/ any unexpected exceptions. Exceptions are exceptional, not "unexpected". IMHO, this is one of the big weaknesses of .Net. It hands you this big thing called "Exception Handling" on a platter, then leaves /you/ to work out what to do with it. Other languages are far more explicit and actually push you to keep Exception Handling very much in mind as you write your code. Every "entry point" into your code (Sub Main, methods that run on Threads, any action that the user initiates) should have its /own/ Try..Catch constructs. Having a global, "catch-all" Exception Handler is /limited/ in its use, and then mainly as a last-resort, back-stop. The most you can do here is to log the error to a file, somewhere. By the time you get here, the program's teetering on the edge, ready to collapse in a messy heap. There's nothing you can do to recover from (or /Handle/) the exception. You have to do that /much/ closer to the site of the problem. HTH,
[quoted text, click to view] "Phill W." <p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-k> wrote in message news:fsg74n$t0n$1@south.jnrs.ja.net... > John wrote: > >> I have a vs2008 winform app that has a start-up form assigned through >> application framework i.e. no Sub Main. > > Why not? > I haven't played with the Application Framework yet and, personally, I > /like/ Sub Main. > >> How can I setup a catchall exception handler to my app to catch >> any unexpected exceptions? > > Apart from the occasional left-field stuff that the Framework throws at > you, you shouldn't /have/ any unexpected exceptions. > > Exceptions are exceptional, not "unexpected". > > IMHO, this is one of the big weaknesses of .Net. > It hands you this big thing called "Exception Handling" on a platter, then > leaves /you/ to work out what to do with it. Other languages are far more > explicit and actually push you to keep Exception Handling very much in > mind as you write your code. > > Every "entry point" into your code (Sub Main, methods that run on Threads, > any action that the user initiates) should have its /own/ Try..Catch > constructs. > > Having a global, "catch-all" Exception Handler is /limited/ in its use, > and then mainly as a last-resort, back-stop. The most you can do here is > to log the error to a file, somewhere. By the time you get here, the > program's teetering on the edge, ready to collapse in a messy heap. > There's nothing you can do to recover from (or /Handle/) the exception. > You have to do that /much/ closer to the site of the problem. > > HTH, > Phill W. So are you positing that one should put a big Try/Catch around the code in Program.cs rather than putting in event handlers for the Application Unhandled Exception and the Unhandled Thread Exception? While we all agree that our applications should not throw unhandled exceptions, what if it does? RobinS.
[quoted text, click to view] "RobinS" <robins@imnottelling.com> wrote in message news:8_CdnXiCz88w3nHanZ2dnUVZ_r6rnZ2d@comcast.com... > While we all agree that our applications should not throw unhandled > exceptions, what if it does? You tell us. If it does throw an unhandled exception, what will your catch-all handler _do_ about it? Log the exception, and then, what? -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
[quoted text, click to view] "Dave" <noone@nowhere.com> wrote in message news:#lYQL#MkIHA.748@TK2MSFTNGP04.phx.gbl... > > "John Saunders [MVP]" <john.saunders at trizetto.com> wrote in message > news:uG40npMkIHA.2304@TK2MSFTNGP05.phx.gbl... >> >> >> "RobinS" <robins@imnottelling.com> wrote in message >> news:8_CdnXiCz88w3nHanZ2dnUVZ_r6rnZ2d@comcast.com... >>> While we all agree that our applications should not throw unhandled >>> exceptions, what if it does? >> >> You tell us. If it does throw an unhandled exception, what will your >> catch-all handler _do_ about it? Log the exception, and then, what? > > throw it, then restart... just like ms's failed initial attempt at sp1 for > vista, fail, restart, fail, restart, fail, restart, ad infinitum, ad > nauseum... sometimes its good to just give up. > If it's unhandled, then your application is probably not in a good enough state for you to know that it makes sense to restart. Depending on what kind of application it is, you're probably better off just not catching such an exception. -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
[quoted text, click to view] "John Saunders [MVP]" <john.saunders at trizetto.com> wrote in message news:uG40npMkIHA.2304@TK2MSFTNGP05.phx.gbl... > > > "RobinS" <robins@imnottelling.com> wrote in message > news:8_CdnXiCz88w3nHanZ2dnUVZ_r6rnZ2d@comcast.com... >> While we all agree that our applications should not throw unhandled >> exceptions, what if it does? > > You tell us. If it does throw an unhandled exception, what will your > catch-all handler _do_ about it? Log the exception, and then, what? throw it, then restart... just like ms's failed initial attempt at sp1 for vista, fail, restart, fail, restart, fail, restart, ad infinitum, ad nauseum... sometimes its good to just give up.
[quoted text, click to view]
John Saunders [MVP] wrote: > "RobinS" <robins@imnottelling.com> wrote in message > news:8_CdnXiCz88w3nHanZ2dnUVZ_r6rnZ2d@comcast.com... >> While we all agree that our applications should not throw unhandled >> exceptions, what if it does? > > You tell us. If it does throw an unhandled exception, what will your > catch-all handler _do_ about it? Log the exception, and then, what? Exit, I assume. It is not there to fix things, it is there to avoid a weird message for the user. The message should inform them that the programmer failed to catch the exception, that it has been logged, and that they should have a nice day.
[quoted text, click to view] "Steve Gerrard" <mynamehere@comcast.net> wrote in message news:wrGdnXUF_uKdN3DanZ2dnUVZ_ommnZ2d@comcast.com... > John Saunders [MVP] wrote: >> "RobinS" <robins@imnottelling.com> wrote in message >> news:8_CdnXiCz88w3nHanZ2dnUVZ_r6rnZ2d@comcast.com... >>> While we all agree that our applications should not throw unhandled >>> exceptions, what if it does? >> >> You tell us. If it does throw an unhandled exception, what will your >> catch-all handler _do_ about it? Log the exception, and then, what? > > Exit, I assume. It is not there to fix things, it is there to avoid a > weird message for the user. The message should inform them that the > programmer failed to catch the exception, that it has been logged, and > that they should have a nice day. > > That's exactly right. Plus, it gives us the exception and a stack trace to work off of to fix the problem. That's better than "the application crashed and we have no idea what it did". It also removes the onus on the user to copy the error message and send it to us. More information is always better. RobinS.
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |