|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Simulating a fatal exceptiontest, but in order to do so (fully), I need generate/simulate a fatal exception (i.e. an exception which is caught but can't be ignored and causes the application to crash.) Thread.CurrentThread.Abort() doesn't seem to be the right choice, does it? I'm only working with the main and UI threads. Any thoughts? Here's my code inside program.cs: [STAThread] static void Main() { CustomExceptionHandler exHandler = new CustomExceptionHandler(); Application.ThreadException += new ThreadExceptionEventHandler(exHandler.OnThreadException); Application.Run(new frmController()); } internal class CustomExceptionHandler { public void OnThreadException(object sender, ThreadExceptionEventArgs t) { // Log the exception ExceptionLogger.LogException(t.Exception); try { // Exit the program if the user clicks Abort. DialogResult result = ShowThreadExceptionDialog(t.Exception); if (result == DialogResult.Abort) { Application.Exit(); } // Otherwise try to continue program execution } catch { // Fatal error, terminate program try { MessageBox.Show("Fatal Error", "Fatal Error", MessageBoxButtons.OK, MessageBoxIcon.Stop); } finally { Application.Exit(); } } } private DialogResult ShowThreadExceptionDialog(Exception ex) { string errorMessage = "Unhandled Exception: " + Environment.NewLine + Environment.NewLine + ex.Message + Environment.NewLine + Environment.NewLine + ex.GetType() + Environment.NewLine + Environment.NewLine + "Stack Trace" + Environment.NewLine + ex.StackTrace; return MessageBox.Show(errorMessage, "Application Error", MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop); } } // End inner class Hi,
All unhandled exceptions can be considered fatal. The ones in particular that you're speaking of, I assume, are StackOverflowException, ThreadAbortException, OutOfMemoryException and ExecutionEngineException. The problem is that simply throwing these exceptions isn't the same as them occurring in a real situation. In a real situation, you're probably not going to be able to handle these exceptions gracefully and should consider them a bug in your code (or possibly the framework in the case of ExecutionEngineException). ThreadAbortException means that a thread was aborted. There's probably not much you can do in a global exception handler routine for this. OutOfMemoryException means that your app has consumed too much memory. - Can't really recover from this either in a global exception handler routine. StackOverflowException probably means that your app is processing an infinitely recursive method call. - Again, it's a bug and you can't really doing anything about this in a global handler. ExecutionEngineException might be a bug in the framework. Global handler won't help here either. (Note: In the case of all except ThreadAbortException, it's highly possible that your global handler won't be able to execute. There may not be enough memory or stack space, or a bug in the framework might cause your application to simply terminate without warning) The point is, if the application is going to crash - your code won't be able to handle it ;) -- Show quoteDave Sexton "Quimbly" <Quim***@discussions.microsoft.com> wrote in message news:D278EEC5-C53A-48FF-B924-DCD4730C723F@microsoft.com... >I have a top-level exception handler for my WinForms app that I'd like to > test, but in order to do so (fully), I need generate/simulate a fatal > exception (i.e. an exception which is caught but can't be ignored and > causes > the application to crash.) > > Thread.CurrentThread.Abort() doesn't seem to be the right choice, does it? > I'm only working with the main and UI threads. > > Any thoughts? > > Here's my code inside program.cs: > [STAThread] > static void Main() > { > CustomExceptionHandler exHandler = new CustomExceptionHandler(); > Application.ThreadException += new > ThreadExceptionEventHandler(exHandler.OnThreadException); > Application.Run(new frmController()); > } > > internal class CustomExceptionHandler > { > public void OnThreadException(object sender, ThreadExceptionEventArgs > t) > { > // Log the exception > ExceptionLogger.LogException(t.Exception); > > try > { > // Exit the program if the user clicks Abort. > DialogResult result = ShowThreadExceptionDialog(t.Exception); > > if (result == DialogResult.Abort) > { > Application.Exit(); > } > // Otherwise try to continue program execution > } > catch > { > // Fatal error, terminate program > try > { > MessageBox.Show("Fatal Error", "Fatal Error", > MessageBoxButtons.OK, > MessageBoxIcon.Stop); > } > finally > { > Application.Exit(); > } > } > } > > private DialogResult ShowThreadExceptionDialog(Exception ex) > { > string errorMessage = > "Unhandled Exception: " + Environment.NewLine + > Environment.NewLine + > ex.Message + Environment.NewLine + Environment.NewLine + > ex.GetType() + Environment.NewLine + Environment.NewLine + > "Stack Trace" + Environment.NewLine + > ex.StackTrace; > > return MessageBox.Show(errorMessage, "Application Error", > MessageBoxButtons.AbortRetryIgnore, > MessageBoxIcon.Stop); > } > } // End inner class Another thing to keep in mind is you can't catch a real
StackOverflowException--there is no stack space available to push the exception... -- Show quoteBrowse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Dave Sexton" wrote: > Hi, > > All unhandled exceptions can be considered fatal. The ones in particular > that you're speaking of, I assume, are StackOverflowException, > ThreadAbortException, OutOfMemoryException and ExecutionEngineException. > > The problem is that simply throwing these exceptions isn't the same as them > occurring in a real situation. In a real situation, you're probably not > going to be able to handle these exceptions gracefully and should consider > them a bug in your code (or possibly the framework in the case of > ExecutionEngineException). > > ThreadAbortException means that a thread was aborted. There's probably not > much you can do in a global exception handler routine for this. > > OutOfMemoryException means that your app has consumed too much memory. - > Can't really recover from this either in a global exception handler routine. > > StackOverflowException probably means that your app is processing an > infinitely recursive method call. - Again, it's a bug and you can't really > doing anything about this in a global handler. > > ExecutionEngineException might be a bug in the framework. Global handler > won't help here either. > > (Note: In the case of all except ThreadAbortException, it's highly possible > that your global handler won't be able to execute. There may not be enough > memory or stack space, or a bug in the framework might cause your > application to simply terminate without warning) > > The point is, if the application is going to crash - your code won't be able > to handle it ;) > > -- > Dave Sexton > > "Quimbly" <Quim***@discussions.microsoft.com> wrote in message > news:D278EEC5-C53A-48FF-B924-DCD4730C723F@microsoft.com... > >I have a top-level exception handler for my WinForms app that I'd like to > > test, but in order to do so (fully), I need generate/simulate a fatal > > exception (i.e. an exception which is caught but can't be ignored and > > causes > > the application to crash.) > > > > Thread.CurrentThread.Abort() doesn't seem to be the right choice, does it? > > I'm only working with the main and UI threads. > > > > Any thoughts? > > > > Here's my code inside program.cs: > > [STAThread] > > static void Main() > > { > > CustomExceptionHandler exHandler = new CustomExceptionHandler(); > > Application.ThreadException += new > > ThreadExceptionEventHandler(exHandler.OnThreadException); > > Application.Run(new frmController()); > > } > > > > internal class CustomExceptionHandler > > { > > public void OnThreadException(object sender, ThreadExceptionEventArgs > > t) > > { > > // Log the exception > > ExceptionLogger.LogException(t.Exception); > > > > try > > { > > // Exit the program if the user clicks Abort. > > DialogResult result = ShowThreadExceptionDialog(t.Exception); > > > > if (result == DialogResult.Abort) > > { > > Application.Exit(); > > } > > // Otherwise try to continue program execution > > } > > catch > > { > > // Fatal error, terminate program > > try > > { > > MessageBox.Show("Fatal Error", "Fatal Error", > > MessageBoxButtons.OK, > > MessageBoxIcon.Stop); > > } > > finally > > { > > Application.Exit(); > > } > > } > > } > > > > private DialogResult ShowThreadExceptionDialog(Exception ex) > > { > > string errorMessage = > > "Unhandled Exception: " + Environment.NewLine + > > Environment.NewLine + > > ex.Message + Environment.NewLine + Environment.NewLine + > > ex.GetType() + Environment.NewLine + Environment.NewLine + > > "Stack Trace" + Environment.NewLine + > > ex.StackTrace; > > > > return MessageBox.Show(errorMessage, "Application Error", > > MessageBoxButtons.AbortRetryIgnore, > > MessageBoxIcon.Stop); > > } > > } // End inner class > > > Hi Peter,
Yes, in 2.0 it's by design however. "StackOverflowException Class" http://msdn2.microsoft.com/en-us/library/system.stackoverflowexception.aspx Although it's possible using a CER according to this article (but I've never tried it myself): "Keep Your Code Running with the Reliability Features of the .NET Framework" http://msdn.microsoft.com/msdnmag/issues/05/10/Reliability/ -- Show quoteDave Sexton "Peter Ritchie [C# MVP]" <PRSoCo@newsgroups.nospam> wrote in message news:41C15F9D-1753-4E64-BB64-841D80DD23A9@microsoft.com... > Another thing to keep in mind is you can't catch a real > StackOverflowException--there is no stack space available to push the > exception... > > -- > Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote. > http://www.peterRitchie.com/blog/ > Microsoft MVP, Visual Developer - Visual C# > > > "Dave Sexton" wrote: > >> Hi, >> >> All unhandled exceptions can be considered fatal. The ones in particular >> that you're speaking of, I assume, are StackOverflowException, >> ThreadAbortException, OutOfMemoryException and ExecutionEngineException. >> >> The problem is that simply throwing these exceptions isn't the same as >> them >> occurring in a real situation. In a real situation, you're probably not >> going to be able to handle these exceptions gracefully and should >> consider >> them a bug in your code (or possibly the framework in the case of >> ExecutionEngineException). >> >> ThreadAbortException means that a thread was aborted. There's probably >> not >> much you can do in a global exception handler routine for this. >> >> OutOfMemoryException means that your app has consumed too much memory. - >> Can't really recover from this either in a global exception handler >> routine. >> >> StackOverflowException probably means that your app is processing an >> infinitely recursive method call. - Again, it's a bug and you can't >> really >> doing anything about this in a global handler. >> >> ExecutionEngineException might be a bug in the framework. Global handler >> won't help here either. >> >> (Note: In the case of all except ThreadAbortException, it's highly >> possible >> that your global handler won't be able to execute. There may not be >> enough >> memory or stack space, or a bug in the framework might cause your >> application to simply terminate without warning) >> >> The point is, if the application is going to crash - your code won't be >> able >> to handle it ;) >> >> -- >> Dave Sexton >> >> "Quimbly" <Quim***@discussions.microsoft.com> wrote in message >> news:D278EEC5-C53A-48FF-B924-DCD4730C723F@microsoft.com... >> >I have a top-level exception handler for my WinForms app that I'd like >> >to >> > test, but in order to do so (fully), I need generate/simulate a fatal >> > exception (i.e. an exception which is caught but can't be ignored and >> > causes >> > the application to crash.) >> > >> > Thread.CurrentThread.Abort() doesn't seem to be the right choice, does >> > it? >> > I'm only working with the main and UI threads. >> > >> > Any thoughts? >> > >> > Here's my code inside program.cs: >> > [STAThread] >> > static void Main() >> > { >> > CustomExceptionHandler exHandler = new CustomExceptionHandler(); >> > Application.ThreadException += new >> > ThreadExceptionEventHandler(exHandler.OnThreadException); >> > Application.Run(new frmController()); >> > } >> > >> > internal class CustomExceptionHandler >> > { >> > public void OnThreadException(object sender, >> > ThreadExceptionEventArgs >> > t) >> > { >> > // Log the exception >> > ExceptionLogger.LogException(t.Exception); >> > >> > try >> > { >> > // Exit the program if the user clicks Abort. >> > DialogResult result = ShowThreadExceptionDialog(t.Exception); >> > >> > if (result == DialogResult.Abort) >> > { >> > Application.Exit(); >> > } >> > // Otherwise try to continue program execution >> > } >> > catch >> > { >> > // Fatal error, terminate program >> > try >> > { >> > MessageBox.Show("Fatal Error", "Fatal Error", >> > MessageBoxButtons.OK, >> > MessageBoxIcon.Stop); >> > } >> > finally >> > { >> > Application.Exit(); >> > } >> > } >> > } >> > >> > private DialogResult ShowThreadExceptionDialog(Exception ex) >> > { >> > string errorMessage = >> > "Unhandled Exception: " + Environment.NewLine + >> > Environment.NewLine + >> > ex.Message + Environment.NewLine + Environment.NewLine + >> > ex.GetType() + Environment.NewLine + Environment.NewLine + >> > "Stack Trace" + Environment.NewLine + >> > ex.StackTrace; >> > >> > return MessageBox.Show(errorMessage, "Application Error", >> > MessageBoxButtons.AbortRetryIgnore, >> > MessageBoxIcon.Stop); >> > } >> > } // End inner class >> >> >> A ThreadOvberflowException can be generated by an unbound recursion:
static void TestStackOverflow() { TestStackOverflow(); } Show quote "Dave Sexton" <dave@jwa[remove.this]online.com> schrieb im Newsbeitrag news:%23disj1KGHHA.3976@TK2MSFTNGP05.phx.gbl... > Hi, > > All unhandled exceptions can be considered fatal. The ones in particular > that you're speaking of, I assume, are StackOverflowException, > ThreadAbortException, OutOfMemoryException and ExecutionEngineException. > > The problem is that simply throwing these exceptions isn't the same as > them occurring in a real situation. In a real situation, you're probably > not going to be able to handle these exceptions gracefully and should > consider them a bug in your code (or possibly the framework in the case of > ExecutionEngineException). > > ThreadAbortException means that a thread was aborted. There's probably > not much you can do in a global exception handler routine for this. > > OutOfMemoryException means that your app has consumed too much memory. - > Can't really recover from this either in a global exception handler > routine. > > StackOverflowException probably means that your app is processing an > infinitely recursive method call. - Again, it's a bug and you can't > really doing anything about this in a global handler. > > ExecutionEngineException might be a bug in the framework. Global handler > won't help here either. > > (Note: In the case of all except ThreadAbortException, it's highly > possible that your global handler won't be able to execute. There may not > be enough memory or stack space, or a bug in the framework might cause > your application to simply terminate without warning) > > The point is, if the application is going to crash - your code won't be > able to handle it ;) > > -- > Dave Sexton > > "Quimbly" <Quim***@discussions.microsoft.com> wrote in message > news:D278EEC5-C53A-48FF-B924-DCD4730C723F@microsoft.com... >>I have a top-level exception handler for my WinForms app that I'd like to >> test, but in order to do so (fully), I need generate/simulate a fatal >> exception (i.e. an exception which is caught but can't be ignored and >> causes >> the application to crash.) >> >> Thread.CurrentThread.Abort() doesn't seem to be the right choice, does >> it? >> I'm only working with the main and UI threads. >> >> Any thoughts? >> >> Here's my code inside program.cs: >> [STAThread] >> static void Main() >> { >> CustomExceptionHandler exHandler = new CustomExceptionHandler(); >> Application.ThreadException += new >> ThreadExceptionEventHandler(exHandler.OnThreadException); >> Application.Run(new frmController()); >> } >> >> internal class CustomExceptionHandler >> { >> public void OnThreadException(object sender, >> ThreadExceptionEventArgs t) >> { >> // Log the exception >> ExceptionLogger.LogException(t.Exception); >> >> try >> { >> // Exit the program if the user clicks Abort. >> DialogResult result = ShowThreadExceptionDialog(t.Exception); >> >> if (result == DialogResult.Abort) >> { >> Application.Exit(); >> } >> // Otherwise try to continue program execution >> } >> catch >> { >> // Fatal error, terminate program >> try >> { >> MessageBox.Show("Fatal Error", "Fatal Error", >> MessageBoxButtons.OK, >> MessageBoxIcon.Stop); >> } >> finally >> { >> Application.Exit(); >> } >> } >> } >> >> private DialogResult ShowThreadExceptionDialog(Exception ex) >> { >> string errorMessage = >> "Unhandled Exception: " + Environment.NewLine + >> Environment.NewLine + >> ex.Message + Environment.NewLine + Environment.NewLine + >> ex.GetType() + Environment.NewLine + Environment.NewLine + >> "Stack Trace" + Environment.NewLine + >> ex.StackTrace; >> >> return MessageBox.Show(errorMessage, "Application Error", >> MessageBoxButtons.AbortRetryIgnore, >> MessageBoxIcon.Stop); >> } >> } // End inner class > > Hi Christof,
ThreadOverflowException doesn't exist in the FCL. If you are referring to StackOverflowException, yes it can be generated by coding a simple recursive function, however that will not help the OP at all. It won't be caught using try..catch, and even if it would there's not much that can be done. There's certainly not much a global exception handler can do about it either. StackOverflowException can no longer be caught in 2.0 using a simple try..catch block. Check out my discussion with Peter in this thread. Microsoft recommends that a CLR host unload the AppDomain when a StackOverflowException occurs if shared state is corrupt. Trying to get a global exception handler to respond to this type of exception is a waste of time. "Reliability Best Practices" http://msdn2.microsoft.com/en-us/library/ms228970.aspx -- Show quoteDave Sexton "Christof Nordiek" <cn@nospam.de> wrote in message news:e3dhfwQGHHA.3872@TK2MSFTNGP06.phx.gbl... >A ThreadOvberflowException can be generated by an unbound recursion: > > static void TestStackOverflow() > { > TestStackOverflow(); > } > > "Dave Sexton" <dave@jwa[remove.this]online.com> schrieb im Newsbeitrag > news:%23disj1KGHHA.3976@TK2MSFTNGP05.phx.gbl... >> Hi, >> >> All unhandled exceptions can be considered fatal. The ones in particular >> that you're speaking of, I assume, are StackOverflowException, >> ThreadAbortException, OutOfMemoryException and ExecutionEngineException. >> >> The problem is that simply throwing these exceptions isn't the same as >> them occurring in a real situation. In a real situation, you're probably >> not going to be able to handle these exceptions gracefully and should >> consider them a bug in your code (or possibly the framework in the case >> of ExecutionEngineException). >> >> ThreadAbortException means that a thread was aborted. There's probably >> not much you can do in a global exception handler routine for this. >> >> OutOfMemoryException means that your app has consumed too much memory. - >> Can't really recover from this either in a global exception handler >> routine. >> >> StackOverflowException probably means that your app is processing an >> infinitely recursive method call. - Again, it's a bug and you can't >> really doing anything about this in a global handler. >> >> ExecutionEngineException might be a bug in the framework. Global handler >> won't help here either. >> >> (Note: In the case of all except ThreadAbortException, it's highly >> possible that your global handler won't be able to execute. There may >> not be enough memory or stack space, or a bug in the framework might >> cause your application to simply terminate without warning) >> >> The point is, if the application is going to crash - your code won't be >> able to handle it ;) >> >> -- >> Dave Sexton >> >> "Quimbly" <Quim***@discussions.microsoft.com> wrote in message >> news:D278EEC5-C53A-48FF-B924-DCD4730C723F@microsoft.com... >>>I have a top-level exception handler for my WinForms app that I'd like to >>> test, but in order to do so (fully), I need generate/simulate a fatal >>> exception (i.e. an exception which is caught but can't be ignored and >>> causes >>> the application to crash.) >>> >>> Thread.CurrentThread.Abort() doesn't seem to be the right choice, does >>> it? >>> I'm only working with the main and UI threads. >>> >>> Any thoughts? >>> >>> Here's my code inside program.cs: >>> [STAThread] >>> static void Main() >>> { >>> CustomExceptionHandler exHandler = new CustomExceptionHandler(); >>> Application.ThreadException += new >>> ThreadExceptionEventHandler(exHandler.OnThreadException); >>> Application.Run(new frmController()); >>> } >>> >>> internal class CustomExceptionHandler >>> { >>> public void OnThreadException(object sender, >>> ThreadExceptionEventArgs t) >>> { >>> // Log the exception >>> ExceptionLogger.LogException(t.Exception); >>> >>> try >>> { >>> // Exit the program if the user clicks Abort. >>> DialogResult result = ShowThreadExceptionDialog(t.Exception); >>> >>> if (result == DialogResult.Abort) >>> { >>> Application.Exit(); >>> } >>> // Otherwise try to continue program execution >>> } >>> catch >>> { >>> // Fatal error, terminate program >>> try >>> { >>> MessageBox.Show("Fatal Error", "Fatal Error", >>> MessageBoxButtons.OK, >>> MessageBoxIcon.Stop); >>> } >>> finally >>> { >>> Application.Exit(); >>> } >>> } >>> } >>> >>> private DialogResult ShowThreadExceptionDialog(Exception ex) >>> { >>> string errorMessage = >>> "Unhandled Exception: " + Environment.NewLine + >>> Environment.NewLine + >>> ex.Message + Environment.NewLine + Environment.NewLine + >>> ex.GetType() + Environment.NewLine + Environment.NewLine + >>> "Stack Trace" + Environment.NewLine + >>> ex.StackTrace; >>> >>> return MessageBox.Show(errorMessage, "Application Error", >>> MessageBoxButtons.AbortRetryIgnore, >>> MessageBoxIcon.Stop); >>> } >>> } // End inner class >> >> > > A your right about ThreadOverflow..., it's a typo.
And about the usefullness, it was only an idea, how to test the ocuurence of such exception, including if such an exception can be caught anyway. (OP talked about simulating a fatal exception). Dave said: "The problem is that simply throwing these exceptions isn't the same as them occurring in a real situation." My 'solution' is a bit nearer to the 'real situation', isn't it? Surely there are some other points to consider, e.g. a stack overflow from unmanaged code may arise different prolems ... Show quote "Dave Sexton" <dave@jwa[remove.this]online.com> schrieb im Newsbeitrag news:OUKwF%23QGHHA.3468@TK2MSFTNGP04.phx.gbl... > Hi Christof, > > ThreadOverflowException doesn't exist in the FCL. If you are referring to > StackOverflowException, yes it can be generated by coding a simple > recursive function, however that will not help the OP at all. It won't be > caught using try..catch, and even if it would there's not much that can be > done. There's certainly not much a global exception handler can do about > it either. StackOverflowException can no longer be caught in 2.0 using a > simple try..catch block. Check out my discussion with Peter in this > thread. > > Microsoft recommends that a CLR host unload the AppDomain when a > StackOverflowException occurs if shared state is corrupt. Trying to get a > global exception handler to respond to this type of exception is a waste > of time. > > "Reliability Best Practices" > http://msdn2.microsoft.com/en-us/library/ms228970.aspx > > -- > Dave Sexton > > "Christof Nordiek" <cn@nospam.de> wrote in message > news:e3dhfwQGHHA.3872@TK2MSFTNGP06.phx.gbl... >>A ThreadOvberflowException can be generated by an unbound recursion: >> >> static void TestStackOverflow() >> { >> TestStackOverflow(); >> } >> >> "Dave Sexton" <dave@jwa[remove.this]online.com> schrieb im Newsbeitrag >> news:%23disj1KGHHA.3976@TK2MSFTNGP05.phx.gbl... >>> Hi, >>> >>> All unhandled exceptions can be considered fatal. The ones in >>> particular that you're speaking of, I assume, are >>> StackOverflowException, ThreadAbortException, OutOfMemoryException and >>> ExecutionEngineException. >>> >>> The problem is that simply throwing these exceptions isn't the same as >>> them occurring in a real situation. In a real situation, you're >>> probably not going to be able to handle these exceptions gracefully and >>> should consider them a bug in your code (or possibly the framework in >>> the case of ExecutionEngineException). >>> >>> ThreadAbortException means that a thread was aborted. There's probably >>> not much you can do in a global exception handler routine for this. >>> >>> OutOfMemoryException means that your app has consumed too much >>> emory. - Can't really recover from this either in a global exception >>> handler routine. >>> >>> StackOverflowException probably means that your app is processing an >>> infinitely recursive method call. - Again, it's a bug and you can't >>> really doing anything about this in a global handler. >>> >>> ExecutionEngineException might be a bug in the framework. Global >>> handler won't help here either. >>> >>> (Note: In the case of all except ThreadAbortException, it's highly >>> possible that your global handler won't be able to execute. There may >>> not be enough memory or stack space, or a bug in the framework might >>> cause your application to simply terminate without warning) >>> >>> The point is, if the application is going to crash - your code won't be >>> able to handle it ;) >>> >>> -- >>> Dave Sexton >>> >>> "Quimbly" <Quim***@discussions.microsoft.com> wrote in message >>> news:D278EEC5-C53A-48FF-B924-DCD4730C723F@microsoft.com... >>>>I have a top-level exception handler for my WinForms app that I'd like >>>>to >>>> test, but in order to do so (fully), I need generate/simulate a fatal >>>> exception (i.e. an exception which is caught but can't be ignored and >>>> causes >>>> the application to crash.) >>>> >>>> Thread.CurrentThread.Abort() doesn't seem to be the right choice, does >>>> it? >>>> I'm only working with the main and UI threads. >>>> >>>> Any thoughts? >>>> >>>> Here's my code inside program.cs: >>>> [STAThread] >>>> static void Main() >>>> { >>>> CustomExceptionHandler exHandler = new CustomExceptionHandler(); >>>> Application.ThreadException += new >>>> ThreadExceptionEventHandler(exHandler.OnThreadException); >>>> Application.Run(new frmController()); >>>> } >>>> >>>> internal class CustomExceptionHandler >>>> { >>>> public void OnThreadException(object sender, >>>> ThreadExceptionEventArgs t) >>>> { >>>> // Log the exception >>>> ExceptionLogger.LogException(t.Exception); >>>> >>>> try >>>> { >>>> // Exit the program if the user clicks Abort. >>>> DialogResult result = ShowThreadExceptionDialog(t.Exception); >>>> >>>> if (result == DialogResult.Abort) >>>> { >>>> Application.Exit(); >>>> } >>>> // Otherwise try to continue program execution >>>> } >>>> catch >>>> { >>>> // Fatal error, terminate program >>>> try >>>> { >>>> MessageBox.Show("Fatal Error", "Fatal Error", >>>> MessageBoxButtons.OK, >>>> MessageBoxIcon.Stop); >>>> } >>>> finally >>>> { >>>> Application.Exit(); >>>> } >>>> } >>>> } >>>> >>>> private DialogResult ShowThreadExceptionDialog(Exception ex) >>>> { >>>> string errorMessage = >>>> "Unhandled Exception: " + Environment.NewLine + >>>> Environment.NewLine + >>>> ex.Message + Environment.NewLine + Environment.NewLine + >>>> ex.GetType() + Environment.NewLine + Environment.NewLine + >>>> "Stack Trace" + Environment.NewLine + >>>> ex.StackTrace; >>>> >>>> return MessageBox.Show(errorMessage, "Application Error", >>>> MessageBoxButtons.AbortRetryIgnore, >>>> MessageBoxIcon.Stop); >>>> } >>>> } // End inner class >>> >>> >> >> > > Hi Christof,
You seem to have missed the point though. I meant that if the OP attempted to throw these exceptions just to test a global handler, it might be able to handle it gracefully, but if they were to occur because of some real issue, then things would work quite differently. I was merely suggesting that these exceptions stand out from the others since you could easily just throw any other exception and get the same results as if they occurred because of some real problem in the program. -- Show quoteDave Sexton "Christof Nordiek" <cn@nospam.de> wrote in message news:eEV4ssTGHHA.2464@TK2MSFTNGP06.phx.gbl... >A your right about ThreadOverflow..., it's a typo. > > And about the usefullness, it was only an idea, how to test the ocuurence > of such exception, including if such an exception can be caught anyway. > (OP talked about simulating a fatal exception). > Dave said: "The problem is that simply throwing these exceptions isn't the > same as them > occurring in a real situation." > My 'solution' is a bit nearer to the 'real situation', isn't it? > > Surely there are some other points to consider, e.g. a stack overflow from > unmanaged code may arise different prolems ... > > "Dave Sexton" <dave@jwa[remove.this]online.com> schrieb im Newsbeitrag > news:OUKwF%23QGHHA.3468@TK2MSFTNGP04.phx.gbl... >> Hi Christof, >> >> ThreadOverflowException doesn't exist in the FCL. If you are referring >> to StackOverflowException, yes it can be generated by coding a simple >> recursive function, however that will not help the OP at all. It won't >> be caught using try..catch, and even if it would there's not much that >> can be done. There's certainly not much a global exception handler can do >> about it either. StackOverflowException can no longer be caught in 2.0 >> using a simple try..catch block. Check out my discussion with Peter in >> this thread. >> >> Microsoft recommends that a CLR host unload the AppDomain when a >> StackOverflowException occurs if shared state is corrupt. Trying to get >> a global exception handler to respond to this type of exception is a >> waste of time. >> >> "Reliability Best Practices" >> http://msdn2.microsoft.com/en-us/library/ms228970.aspx >> >> -- >> Dave Sexton >> >> "Christof Nordiek" <cn@nospam.de> wrote in message >> news:e3dhfwQGHHA.3872@TK2MSFTNGP06.phx.gbl... >>>A ThreadOvberflowException can be generated by an unbound recursion: >>> >>> static void TestStackOverflow() >>> { >>> TestStackOverflow(); >>> } >>> >>> "Dave Sexton" <dave@jwa[remove.this]online.com> schrieb im Newsbeitrag >>> news:%23disj1KGHHA.3976@TK2MSFTNGP05.phx.gbl... >>>> Hi, >>>> >>>> All unhandled exceptions can be considered fatal. The ones in >>>> particular that you're speaking of, I assume, are >>>> StackOverflowException, ThreadAbortException, OutOfMemoryException and >>>> ExecutionEngineException. >>>> >>>> The problem is that simply throwing these exceptions isn't the same as >>>> them occurring in a real situation. In a real situation, you're >>>> probably not going to be able to handle these exceptions gracefully and >>>> should consider them a bug in your code (or possibly the framework in >>>> the case of ExecutionEngineException). >>>> >>>> ThreadAbortException means that a thread was aborted. There's probably >>>> not much you can do in a global exception handler routine for this. >>>> >>>> OutOfMemoryException means that your app has consumed too much >>>> mory. - Can't really recover from this either in a global exception >>>> handler routine. >>>> >>>> StackOverflowException probably means that your app is processing an >>>> infinitely recursive method call. - Again, it's a bug and you can't >>>> really doing anything about this in a global handler. >>>> >>>> ExecutionEngineException might be a bug in the framework. Global >>>> handler won't help here either. >>>> >>>> (Note: In the case of all except ThreadAbortException, it's highly >>>> possible that your global handler won't be able to execute. There may >>>> not be enough memory or stack space, or a bug in the framework might >>>> cause your application to simply terminate without warning) >>>> >>>> The point is, if the application is going to crash - your code won't be >>>> able to handle it ;) >>>> >>>> -- >>>> Dave Sexton >>>> >>>> "Quimbly" <Quim***@discussions.microsoft.com> wrote in message >>>> news:D278EEC5-C53A-48FF-B924-DCD4730C723F@microsoft.com... >>>>>I have a top-level exception handler for my WinForms app that I'd like >>>>>to >>>>> test, but in order to do so (fully), I need generate/simulate a fatal >>>>> exception (i.e. an exception which is caught but can't be ignored and >>>>> causes >>>>> the application to crash.) >>>>> >>>>> Thread.CurrentThread.Abort() doesn't seem to be the right choice, does >>>>> it? >>>>> I'm only working with the main and UI threads. >>>>> >>>>> Any thoughts? >>>>> >>>>> Here's my code inside program.cs: >>>>> [STAThread] >>>>> static void Main() >>>>> { >>>>> CustomExceptionHandler exHandler = new CustomExceptionHandler(); >>>>> Application.ThreadException += new >>>>> ThreadExceptionEventHandler(exHandler.OnThreadException); >>>>> Application.Run(new frmController()); >>>>> } >>>>> >>>>> internal class CustomExceptionHandler >>>>> { >>>>> public void OnThreadException(object sender, >>>>> ThreadExceptionEventArgs t) >>>>> { >>>>> // Log the exception >>>>> ExceptionLogger.LogException(t.Exception); >>>>> >>>>> try >>>>> { >>>>> // Exit the program if the user clicks Abort. >>>>> DialogResult result = ShowThreadExceptionDialog(t.Exception); >>>>> >>>>> if (result == DialogResult.Abort) >>>>> { >>>>> Application.Exit(); >>>>> } >>>>> // Otherwise try to continue program execution >>>>> } >>>>> catch >>>>> { >>>>> // Fatal error, terminate program >>>>> try >>>>> { >>>>> MessageBox.Show("Fatal Error", "Fatal Error", >>>>> MessageBoxButtons.OK, >>>>> MessageBoxIcon.Stop); >>>>> } >>>>> finally >>>>> { >>>>> Application.Exit(); >>>>> } >>>>> } >>>>> } >>>>> >>>>> private DialogResult ShowThreadExceptionDialog(Exception ex) >>>>> { >>>>> string errorMessage = >>>>> "Unhandled Exception: " + Environment.NewLine + >>>>> Environment.NewLine + >>>>> ex.Message + Environment.NewLine + Environment.NewLine + >>>>> ex.GetType() + Environment.NewLine + Environment.NewLine + >>>>> "Stack Trace" + Environment.NewLine + >>>>> ex.StackTrace; >>>>> >>>>> return MessageBox.Show(errorMessage, "Application Error", >>>>> MessageBoxButtons.AbortRetryIgnore, >>>>> MessageBoxIcon.Stop); >>>>> } >>>>> } // End inner class >>>> >>>> >>> >>> >> >> > > A ThreadAbortException is special in the fact that the CLR will stop this
from being a fatal exception, since to the nature of how it works (it throws itself automatically even if it is caught so that all finally statments associated with try blocks can be executed). If you want to test your unhandled exception event handler just throw a normal exception anywhere in your code without having an explicit catch in place and it will hit your ThreadException event. Mark. Show quote "Quimbly" wrote: > I have a top-level exception handler for my WinForms app that I'd like to > test, but in order to do so (fully), I need generate/simulate a fatal > exception (i.e. an exception which is caught but can't be ignored and causes > the application to crash.) > > Thread.CurrentThread.Abort() doesn't seem to be the right choice, does it? > I'm only working with the main and UI threads. > > Any thoughts? > > Here's my code inside program.cs: > [STAThread] > static void Main() > { > CustomExceptionHandler exHandler = new CustomExceptionHandler(); > Application.ThreadException += new > ThreadExceptionEventHandler(exHandler.OnThreadException); > Application.Run(new frmController()); > } > > internal class CustomExceptionHandler > { > public void OnThreadException(object sender, ThreadExceptionEventArgs t) > { > // Log the exception > ExceptionLogger.LogException(t.Exception); > > try > { > // Exit the program if the user clicks Abort. > DialogResult result = ShowThreadExceptionDialog(t.Exception); > > if (result == DialogResult.Abort) > { > Application.Exit(); > } > // Otherwise try to continue program execution > } > catch > { > // Fatal error, terminate program > try > { > MessageBox.Show("Fatal Error", "Fatal Error", > MessageBoxButtons.OK, > MessageBoxIcon.Stop); > } > finally > { > Application.Exit(); > } > } > } > > private DialogResult ShowThreadExceptionDialog(Exception ex) > { > string errorMessage = > "Unhandled Exception: " + Environment.NewLine + > Environment.NewLine + > ex.Message + Environment.NewLine + Environment.NewLine + > ex.GetType() + Environment.NewLine + Environment.NewLine + > "Stack Trace" + Environment.NewLine + > ex.StackTrace; > > return MessageBox.Show(errorMessage, "Application Error", > MessageBoxButtons.AbortRetryIgnore, > MessageBoxIcon.Stop); > } > } // End inner class You can prevent ThreadAbortException from escalating by using
Thread.ResetAbort() which itself will cause an exception of there are no pending ThreadAbortExceptions. On Tue, 05 Dec 2006 22:04:01 +0100, Mark R. Dawson <MarkRDaw***@discussions.microsoft.com> wrote: > A ThreadAbortException is special in the fact that the CLR will stop this > from being a fatal exception, since to the nature of how it works (it > throws > itself automatically even if it is caught so that all finally statments > associated with try blocks can be executed). If you want to test your > unhandled exception event handler just throw a normal exception anywhere > in > your code without having an explicit catch in place and it will hit your > ThreadException event. > > Mark. -- Happy Coding! Morten Wennevik [C# MVP]  |
|||||||||||||||||||||||
Other interesting topics