Global application error handler
Is there an easy way to define a global error handler for my windows app? Something to catch the exceptions that fall through any other specific try / catches I may have? I've tried the following 2 methods and errors still seem to escape my try / catch block:
1. Attach a handler to the ThreadException event of the application.
2. Put a Try block around my Application.Run call that starts the message loop.
They both seem to work some of the time but i'm sure there is a standardized way to do this and I'm sure i'm also probably missing something completely obvious. Any help anyone can provide?
I've had good luck with the ThreadException event of the Application object, and believe it's the accepted way to do this. This only works, however, if you hook the event before the main form loads -- this means that you HAVE to use Application.Run to load the form, and hook the event before you call Application.Run.
Have you tried this, and still had it fail? I have not seen that happen, but it could be something specific to your app.
Ken, i know threadexception is good for windows app, it let your thread continue when the error is not too severe. but sometime it's not want, when you run something else on some other thread and ThreadException will ignore this.my suggestion is try to do it on the AppDomain.CurrentDomain.UnhandledException , though you lose out some flexibilty compare to ThreadException. consider this if you think an exception from other thread is important.
BTW, Ken, since you also a database guru, can i ask you a small favour. i need an accounting and HR database schema, for personal finance and small business. with little or no knowledge in HR and accounting, it's kind of hard to design it my own, considereing it is just for personal and family run business. well i work in healthcare industry.
thanks and advance
In a simple WinForms application, the AppDomain.UnhandledException event won't do much good.
I have no knowledge of HR and/or accounting. If I was ever involved in any database projects or books, it was only as the "programming guy", making the database do things the database folks didn't think were possible or feasible. Database design in public? I don't think so.
Previously i used the ThreadException a lot in my app, but the behaviour seem to be inconsistent, when what i did was just error logging , this behaviour , I think is a factor of threadings, remoting framework , as well as cross appdomain/processcomunication. well i have a lot of stuff running on the backgorud doing data transfer from/ to the client.
although AppDomain.UnhandledException is less fexible, (users don't like it when an error seem to be minor crash the app to a halt), it helps a lot on the debuggging and fixing as a result of better error logging and tracing.
I'll never doubt that ThreadException is a much better mechanism. except in our application it just doesn't seemed so.
about the database , i 'm doing some simple app , using MS Excel as the UI and i need a reliable and efficient backend to store the data. working mostly in healthcare/ hospital management/ public healt application. i've got no cluew about accounting or HR. a commerciall app, like Quicken is too complex for a small family run business. may be i should investigate those commercial app.
Sorry for the delay in the reply, that is exactly what I did, and exceptions would still*space
space*to the debugger instead of being handled for some reason. It seems to be inconsistent though. I'll try to get a better example for you, but I have a question before that. Does the ThreadException event only apply to the the thread that the main message loop is on or to any threads spawned in the application? This error handler is mainly meant to be a last resort to catch exceptions unhandled elsewhere and log them for future debugging, in almost every case this will not be hit. The AppDomain.UnhandledException event sounds almost like exactly what I want to do. Why won't that event be hit? Sorry for my lack of knowledge on this, I'm mainly and ASP.Net person and we then decided to go WinForms and I'm trying to play catch up with my knowledge of them.
Thanks,
Paul Tyng
the reason for your application to*space
space*into a debugger is your process is attacher to a managed debugger or your DbgJITDebugLaunchSetting it set so. that's why when unhandled exeption is thrown and the thread is not taking care of it you'll see a dialog to choose a debugger(DbgManagedDebugger) eventhoug you do not actually attache the process to a debugger.
AppDomain UnhandledException will always run, because when you choose to attaceh the denugger, the CLR will check it's exixtese.
but all this will not be aproblem on the client machine because you don't have a dubuuger attah to the process.
your debugger will normally point to the VS.Net
BTW , even you sre debugging the process, you could always click continue to see the appDOmain UnhandledException in process.
Be warn that , this last miniute resort used only for clean up and logging only, there'e not much life less anymore in the process
