Im wondering if when a fatal exception occurs in a try block which I cannot handle (OutOfMemory for example) will it still be able to send a notification in catch/finally block to tell me that the console application has stopped?
if not, what would be the proper way to send a notification in case of a fatal error?
Related
I have these lines in my App.xaml.cs, to globally catch the exceptions:
this.Dispatcher.UnhandledException += new
DispatcherUnhandledExceptionEventHandler(
Current_DispatcherUnhandledException);
AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(
CurrentDomain_UnhandledException);
Application.Current.DispatcherUnhandledException += new
DispatcherUnhandledExceptionEventHandler(
Current_DispatcherUnhandledException);
Most exceptions can be caught and a log file will be generated so that I know what is causing the error. But on my customer's PC (only windows 8 has
this problem), the WPF application sometimes crashed but I was not able to get the exception log, means the exception handlers above was not called.
Is there any handler I can set to catch exception? Or is there any log collector/reader like android DDMS for Windows/WPF app?
Thank you!
Since .NET 4.0 you could try and HandleProcessCorruptedStateExceptionsAttribute This attribute allows you to handle exceptions that since .Net 4 terminate the process. This is rather dangerous as you are allowing a process to continue (handle the exception) even when its memory has become corrupted.
In general: do not trust the application after catching such an exception. Log the exception and stop the application. Only when you know what is causing the exception and you are sure the application can recover you could apply this attribute to a method and make it resume normal execution.
I have the following code in my application that is running after an unhandled exception:
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
var exception = e.ExceptionObject as Exception;
if (exception != null) MessageBox.Show(exception.Message + " - " + exception.StackTrace);
}
but even if i catch unhandled exception my windows mobile application close. How to prevent closing application when i catch unhandled exception. I never want to close my app. I want to open Login form in this scenario or anything else not close app.
So what i want is to prevent closing application from unhandled exception like network is down,...
I can not use try catch in every code ....
Any idea how to prevent closing app when network is down or any other unhandled exceptions?
You don't. When you get an AppDomain unhandled exception, your app is no longer in a stable state. Where exactly would you resume to? When you've gotten to that point, your only option, with good reason, is to exit. You could reasonably schedule yourself to run again to make sure the app comes back, but a far better idea is to actually handle the exception at its source and prevent it from being an UnhandledException.
In your app.config add the following element
<runtime>
<!-- the following setting prevents the host from closing when an unhandled exception is thrown -->
<legacyUnhandledExceptionPolicy enabled="1" />
</runtime>
You can, and you should use try...catch and handle the exceptions in every situation where an exception might occur. (In languages like Java you can't even compile your code until you catch every exception that the called function might throw or declare explicitly that this particular function won't catch it, so the one that calls it should do it.)
If you want to minimize the cases where you use try...catch some bad situations can be prevented with testing if the necessary conditions are met so you won't even call a function that is known for throwing a particular exception. Like calling
if (myByteArray != null)
{
myIPAddress = new IPAddress(myByteArray);
}
because this way the IPAddress constructor won't throw an ArgumentNullException.
However in most of the cases this can't be done, especially with networking, because you can't predict if the cable will be cut, the signal will be lost, the database server will crush, etc. in the middle of the transaction. So you should try...catch every time you connect to the network or send data to or receive data from a connection.
AppDomain.CurrentDomain.UnhandledException fires on any unhandled exception on
any thread, but since CLR 2.0, the CLR forces application shutdown after your event
handler completes. However, you can prevent shutdown by adding the following to
your application configuration file:
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="1" />
</runtime>
</configuration>
I think you need to use Application.ThreadException
When you subscribe to Application.ThreadException, unhandled exceptions wont hit the UnhandledException and the app will keep running.
When setting up NServiceBus with MSMQ using the standard IServer config options, you define:
an input queue
an error queue.
When your NServiceBus Message Handler fails handling the message for whatever reason, it throws an exception and moves the message to the error queue.
Is the message in the error queue the exact same message that was in the input queue? If so, which I imagine it is, is there any way to know why those messages failed? Is there any metadata attached to them that might contain the original exception that was thrown?
Being able to do this would be especially useful in scenarios when your Handler is set to retry a number of times greater than one. This is because even if fatal errors might be thrown in the Handler, and logged, they're not really Fatal as such until they go in the error queue, because that's when they've actually failed.
Any ideas?
cheers
It's an exact copy of the message that is send to the error q. The message id and source queue is stored in the headers to enable the message to be replayed. In 2.5 there is no good way to get the exception details for the failed message so you have to correlate the message id with entries the logfiles. The fact that NSB reties for you will often cause the same logmessage to be displayed multiple times for a message so make sure to use the last entry.
This is of course not very user friendly and has been fixed in the upcoming 3.0 where you can register Failure managers that let's you hook into NSB to get this info. The default Failure Manager will put the exception details in a headers so that you can easy get at them by looking at the failed message.
I have a client server application. The clients log in an account on my server. The thing is that my server sometimes crashes and although I have all kind of wrapped in a try-catch statement, I get no message.
The server I have implemented is here: simple threaded tcp server.
Did anyone encounter a crash like this? Is there a place that I can find an error log for the app?
I'm kind of desperate, so ANY ideas would be great. Thanks.
The application is possible to crash because of unhandled exceptions even if you have all functions wrapped in try-catch block because of multi-threading operations.
try
{
var t = new Thread(()=>
{
Thread.Sleep(5000);
throw new Exception();
});
t.Start();
//t.Join();
}
catch
{
//you can't deal with exception here
//even though you uncomment `t.Join`
//the application will crash even there is a try-catch wrapped
}
Have you kept this part of the example code?
Add a Console.WriteLine right after the catch...
catch
{
//a socket error has occured
break;
}
If you're running under Debug mode in Visual Studio, you might consider enabling CLR Exceptions to propagate to user control. I believe they're disabled by default, which sometimes causes hung applications without any debugger feedback. This article on MSDN might be of interest.
how to catch any error on my C# program and show any message instead of crushed
i can do try & catch - but i don't know when or where in other place it will crush
i need something that will catch any unknown error
thanks in advance
If your exception is happening in a console app, or in a background thread on a win forms app, you can use the AppDomain.UnhandledException event to determine what exception fired.
In the case of a Windows Forms application, use the Application.ThreadException event.
In both cases, your application will still terminate, but it gives you an opportunity to log the exception and return gracefully. You can not use this to hide the exception, and continue running like nothing ever happened.
For completeness, if this is an ASP.NET application, then you can handle the error in the Application_Error method in the global.asax file which is handling the HttpApplication.Error event.