I've a WPF application which runs globally fine. But sometimes, the client tell me that he gots some crashes. But I've no information about what happened except what he does.
Is there a way to put a global try{}catch(Exception){LOGEXCEPTION; throw;} somewhere to receive all exceptions generated by a GUI action, or any other option.
Something like a "Last remedy" to log exception that we didn't manage well?
Thank you!
By handling the following events, you should be able to catch the vast majority (if not all) unhandled exceptions in your application:
Application.DispatcherUnhandledException
AppDomain.CurrentDomain.UnhandledException
Related
Possibly an obvious question to some but couldn't find a duplicate.
I'm packaging the final version of a Windows Forms solution I've been working on and am getting it ready for online distribution. What are the best practices when doing so? We've already had some trouble with packaging the installation file and have run into hurdles to test the program on different PCs, both 32 and 64-bit included.
More specifically, should "throw;" commands be commented out or left in the final release? Would this expose any of the inner workings of the solution itself?
Released application should not crash when exception occurs. You will want to inform the user, something went wrong and log your exception, but you do not want to crash! Informing user should be done in a friendly manner and not just by putting exception.ToString() into the message box.
It is a good practice to add Application.ThreadException or AppDomain.CurrentDomain.UnhandledException handlers to handle all exceptions in your Application. How exactly to do that, is answered in the following thread: Catch Application Exceptions in a Windows Forms Application
However, make sure that your application survives in a usable state, i.e. handle exceptions in a proper way for your application.
I usually add a preprocessor directive for handling exceptions on the application level, since I want them to trow while debugging. For example:
#if !DEBUG
Application.ThreadException += new ThreadExceptionEventHandler(MyHandler);
#endif
It should also be mentioned, that if you have code pieces where you anticipate that Exception might occur, such as network communication error, you should handle those pieces explicitly. What I am saying is, we should not completely forget about exception handling, just because we configured an unhandled exception handler on the application level.
Keep all of your exception handling intact.
Add an event to the starting form in the application, attaching to the Application.UnhandledException event. This will fire if an exception propogates up the stack.
This is the point to inform the user that the application has crashed. Log the error here and then abort gracefully.
Your point about revealing internals, thats up to you to decide. You can obfuscate the source code if you wish, but if you are releasing in Release build mode, and you are not providing the .PDB, then this is the first step.
Ultimately, the DLL / EXE can be decompiled anyway, so its up to you. Debug mode will reveal a lot more than Release mode, but not much more.
Ideally, you should be catching anything that's thrown higher with throw;. Carefully check your code and try to ensure that thrown exceptions are dealt with appropriately. Unhandled exceptions are logged - you can see this information in the Windows Event Viewer. Depending on what details you put in them, unhandled exceptions could give clues as to the inner workings of your application. However, I would suggest that unhandled exceptions are a poor source of information, and that anyone who wanted to know how your application worked could simply disassemble it, unless you've obfuscated it.
Some exceptions cannot be caught by surrounding code with try/catch blocks, so your application should also implement an unhandled exception handler. This gives you the opportunity to show the user an error message and do something with the exception - log it, send it to support, discard it, etc.
I am using windows service in c# for file transfer using sFTP (ssh.net).
I have handled exception in each and every block of code still i am getting unhandled exception and my my windows service gets crashed.
i figured out about unhandled exception by using
AppDomain.CurrentDomain.UnhandledException
Is is possible to avoid this unhandled exception and avoid service from being crashed.
Thanks in advance.
Vijay
No, because UnhandledException does not change the fact that the process is going down. It just gives you the chance to do something (e.g. log the failure) before that happens.
Even if things could work like that, the fact is that your service has bugs. You should be looking more to fix them and less to hide them.
Is is possible to avoid this unhandled exception and avoid service from being crashed.
Yes, it is. It is also a bad design decision.
AppDomain.CurrentDomain.UnhandledException
This is a good place to put in a last resort handler that writes a crash report, then restarts the service.
Swallowing exceptions is not smart. EVERY exception you expect has to be handled.
I have handled exception in each and every block of code still i am getting unhandled
exception
Sounds like you do not know what you are doing. It is not necessary to handle exceptions in every code block - it totally overloads your code with exception handlers. It is necessary, though, to have proper exception handling where it makes sense and to catch EVERY SENSIBLE (expectable) exception.
Avoiding the service from crashing is not smart - because if you do not know what exception you have, then you may end up with a corrupt service instead of a crashed one. Fail fast and hard is still the ONLY way to write reliable server systems.
The only way to avoid an unhandled exception is not to have one! Assuming your service doesn't make use of any multi-threading capabilities which could throw exceptions on separate threads, you can get away with putting an exception handler around your ServiceBase.Run call
This way any exceptions that slip through can be caught at the very last minute and handled. Usually though you want to try and grab these lower down and handle accordingly
With threaded applications it becomes a little more difficult as each new thread that is spawned won't throw on the main thread and won't be handled by this 'catch-all' handler.
Edit:
I might add that I don't condone doing this - ideally you should be handling exceptions in the right places - if you are getting unhandled exceptions you aren't expecting, then you need to examine the stack and see what went wrong. Adding a handler to AppDomain.UnhandledException and writing the exception tree and stack to the log will help (you do have some logging mechanism, right?). Either that or debugging
I am having a nasty bug show up in the wild, and I can't put my finger on it. Is there a way to have a Global Try/Catch block, or a way to handle any exception that is unhanded in Monotouch.
Can I just wrap UIApplication.Main(args) in a try catch?
After the exception is caught, Id like to show a UIAlertView to display the results.
Any help?
You can wrap UIApplication.Main (args) in a try {} catch {} but you will not be able to show a UIAlertView at that point, since we've unwound the entire stack including all the UI. What you could do is log the exception to a crash file in the Documents folder of your application bundle, and show that on the next launch or upload it to a web service.
The Exceptioneer guys were working on MonoTouch support as well, which might be worth looking into.
I have had success with using the unhandled exception handler, ie AppDomain.CurrentDomain.UnhandledException event. This seems to catch many (but not all) unhandled exceptions. It seems that crashes that are in unmanaged code can cause the app to fail without calling this event.
Geoff: would capturing this event in addition to catching exceptions falling out of UIApplication.Main make sense or would one of the methods be preferred?
I have an application that, as any other app, crashes once in a while for various reasons.
When it crashes, it does it gracefully and the users get a nice message of the crash. At the same time the crash is reported on the server for analysis so it can be fixed in future versions. However, I would like that the app keeps working through the crash.
What that means is that I would like to run the forms in an 'atomic' way. If it goes down, it doesn't take down the entire app. The users should just need to start over the work done with the particular form.
Is this something that can be done through architecture? Or maybe the new framework versions has something to aid this?
The application is build mostly in C# over the 3.5 framework, but it also uses some external references, some COMs and web service references.
I am not interested in an answer: 'well fix the crashes'. Me and my team and the testing team are working round the clock for this.
Also handling the AppDomain.CurrentDomain.UnhandledException event may help.
Depending on what type of application it is there is an un-handled exception handler
in most appliactions.
In a Web Applications the System.Web.HttpApplication has an Error event.
In a Wpf Applications System.Windows.Application has a DispatcherUnhandledException event.
In Windows forms the System.Windows.Forms.Application has a ThreadException event.
You can hook in to these events and handle any exception which is out of your control.
You need to catch the exceptions (assuming that it is exceptions that are being raised) at the most appropriate level.
If you want the application to carry on if the current form raises an exception then you'll need something like the following code:
try
{
// Show your form
}
catch (YourException ex)
{
// log the exception
}
If more than one exception can be raised then these should be trapped explicitly - don't trap Exception.
So I am sold on the concept of attempting to collect data automatically from a program - i.e., popping up a dialog box that asks the user to send the report when something goes wrong.
I'm working in MS Visual Studio C#.
From an implementation point of view, does it make sense to put a try/catch loop in my main program.cs file, around where the application is run? Like this:
try
{
Application.Run(new myMainForm());
}
catch (Exception ex)
{
//the code to build the report I want to send and to
//pop up the Problem Report form and ask the user to send
}
or does it make sense to put try/catch loops throughout pieces of the code to catch more specific exception types? (I'm thinking not because this is a new application, and putting in more specific exception catches means I have an idea of what's going to go wrong... I don't, which is why the above seems to make sense to me.)
-Adeena
I think you are right, you would not know what's going to go wrong, which is the point.
However, you might as well consider adding a handler to the ThreadException event instead.
The code above will work but there will be scenarios where multi threading might be an issue with such code, since not all code inside your windows forms program will be running in the main Application.Run loop thread.
Here's a sample code from the linked article:
[STAThread]
static void Main()
{
System.Windows.Forms.Application.ThreadException += new ThreadExceptionEventHandler(ReportError);
System.Windows.Forms.Application.Run(new MainForm());
}
private static void ReportError(object sender, ThreadExceptionEventArgs e)
{
using (ReportErrorDialog errorDlg = new ReportErrorDialog(e.Exception))
{
errorDlg.ShowDialog();
}
}
More documentation on MSDN.
On a minor point, using the ThreadException event also allow your main message loop to continue running in case the exception isn't fatal (i.e. fault-tolerance scenarios) whilst the try/catch approach may requires that you restart the main message loop which could cause side effects.
From an implementation point of view, does it make sense to put a try/catch loop in my main program.cs file, around where the application is run?
Sure and always.
You should use Try/Catch-Blocks wherever you do something critical, that might raise an exception.
Therefore you can not really stick to a pattern for that, because you should now, when what exception will be raised. Otherwise these are unhandled exceptions, which let your program crash.
But there are many exceptions, that need not to stop the application entirely, exceptions, that just can be swallowed over, as they are expected and do not critically need the application to stop. Example for that are UnauthorizedAccessExceptions when moving or accessing data with your programm.
You should try to keep you Try/Catch-Blocks as small as needed, as well as to use not too much of them, because of performance.
Some out there use Try/Catch for steering the program's execution. That should entirely be avoided wherever possible, cause raising an Exception is performance killer number 1.
Wrapping a try catch around the whole application will mean the application will exit upon error.
While using a try and catch around each method is hard to maintain.
Best practice is to use specific try catches around units of code that will throw specific exception types such as FormatException and leave the general exception handling to the application level event handlers.
try
{
//Code that could error here
}
catch (FormatException ex)
{
//Code to tell user of their error
//all other errors will be handled
//by the global error handler
}
Experience will tell you the type of things that could go wrong. Over time you will notice your app often throwing say IO exceptions around file access so you may then later catch these and give the user more information.
The global handlers for errors will catch everything else. You use these by hooking up event handlers to the two events System.Windows.Forms.Application.ThreadException (see MSDN) and AppDomain.UnhandledException (see MSDN)
Be aware that Out of Memory exceptions and StackOverflowException may not be caught by any error catching.
If you do want to automatically get stack traces, Microsoft do allow you to submit them via the Error Reporting Services. All you need to do is sign up for a Digital Certificate from VeriSign and register it (for free) with Microsoft.
Microsoft then gives you a login for you to download the mini-dumps from a website, which are submitted when a user clicks "Send Error Report".
Although people can hit "Don't Send", at least it is a Microsoft dialog box and possibly not one that you have to code yourself. It would be running 24/7, you wouldn't have to worry about uptime of your web server AND you can submit workaround details for users AND you can deliver updates via Windows Update.
Information about this service is located in this "Windows Error Reporting: Getting Started" article.
The best approach is to sing up for
AppDomain.UnhandledException and Application.ThreadException In your application's main function. This will allow you to record any unhandled exceptions in your application. Wraping run in a try catch block does not catch every thing.
if you just want to capture crashes, then ignore all errors and let DrWatson generate a minidump for you. Then you can look at that ina debugger (windbg is preferred for minidumps) and it'll show you the line your code went wrong on, and also all the parameters, stack trace, and registers. You can set Drwatson to generate a full dump where you'll get an entire memory core dump to investigate.
I wouldn't recommend putting a try/catch around the entire app unless you want your app to never "crash" in front of the user - it'll always be handled, and probably ignored as there's nothing you can do with the exception at that point.
Sending the minidump to you is another matter though, here's an article, you'll have to do some work to get it sent via email/http/ftp/etc.