I have been crawling the Internet for quite a long time in hope of a solution, and I've come across a number of answers, but none of these seem to achieve what I want.
I'm trying to handle exceptions without causing the app to crash. Rather than the app simply exiting, I would rather capture the exception, present the user with a more user-friendly error (perhaps a messagebox warning) and allow them to continue operation in the app.
Is it possible to stop the app from bailing out?
The way I'm currently attempting to catch this is like the following:
public class Login : Activity
{
int count = 1;
Session mySession;
protected override void OnCreate(Bundle bundle)
{
AndroidEnvironment.UnhandledExceptionRaiser += HandleAndroidException;
base.OnCreate(bundle);
// Set our view from the "main" layout resource
SetContentView(Resource.Layout.Login);
Button button = FindViewById<Button>(Resource.Id.Login);
string accountCode = Resource.Id.AccountCode.ToString();
string password = Resource.Id.Password.ToString();
// button.Click += delegate { button.Text = string.Format("{0} clicks!", count++); };
button.Click += delegate
{
throw new Exception("LETS THROW A RANDOM EXCEPTION");
};
}
void HandleAndroidException(object sender, RaiseThrowableEventArgs e)
{
Log.Error("INTERNAL DEBUG", "PLEASE HANDLE MY EXCEPTION!");
e.Handled = true;
System.Console.Write("YOU'VE JUST BEEN HANDLED!");
}
}
As you can see I am throwing a general exception and attempting to catch this with an UnhandledExceptionRaiser. I used this as a reference: http://androidapi.xamarin.com/index.aspx?link=E%3AAndroid.Runtime.AndroidEnvironment.UnhandledExceptionRaiser
I am able to find my message in the "Android Device Logging" tool, however it is being triggered AFTER an unhandled exception error occurs. I think this means something inside of Xamarin is having first crack at the exception and falling over. Surely there has to be a way of stopping this??
I have seen countless examples online where people have been asking similar questions and there has been no clear solution. Some people have offered some solutions, but these don't actually do what I had anticipated.
It is literally mind boggling to me if this cannot be done.
This is my first time using Xamarin and also my first time developing a mobile app so I apologise if I'm being ignorant about anything.
Please help!!!
There is one important thing you have to understand about the nature of an Unhandled exception in Android, there isn't one.... in Android framework which uses Java it's an Uncaught exception which means you can't "handle" it or recover from it like you maybe would in a .Net environment. Xamarin(Mono) internally "handles" those uncaught exceptions by surrounding literally everything with try-catch and raising the Unhandled event but that is besides the point. It is also discouraged to interact with the UI as well for various reasons.
Theoretically there are several "workarounds" for displaying a dialog to the user or restarting the app, none of which I'd recommend on doing. Instead you should surround sensitive areas with try-catch clauses to handle expected exceptions, as for the unexpected one's just use an exception reporting component and update your app after analyzing the reported exceptions.
Also, I would move the event subscription to the Application class but that is a personal preference.
Like so:
public class YourAppClass : Application
{
public override void OnCreate()
{
AndroidEnvironment.UnhandledExceptionRaiser += HandleAndroidException;
}
}
Related
I started a blank WPF application (shown below) to implement HockeyApp crash reporting. When the program starts, a window popups up with a single button for the user to press. When the user clicks it the handler attempts to divide by zero and crashes the app. I was receiving crash reports and everything was running smoothly UNTIL I mimicked our bigger system's error catching method, which was to use the DispatcherUnhandledException Event Handler to catch "uncaught" exceptions and then call System.Environment.Exit(0) to gracefully end anything in the background. Now the HockeyApp api isn't sending crash reports. I'm wondering if catching the exceptions at a higher level makes HockeyApp think "Oh, they got things under control" and won't register a "crash."
I'm currently talking to the HockeyApp support staff about this, but I'm wondering if anyone else has had this problem. Should I take out the Exit(0) line, or is there a better practice for exiting an app when we have an uncaught exception? I've tried changing the error code from 0 to 574 (ERROR_UNHANDLED_EXCEPTION) with no result. I don't believe there's any data that we need to save, other than what the HockeyApp api already has.
App class:
public partial class App : Application
{
protected override void OnStartup(StartupEventArgs e)
{
base.OnStartup(e);
RegisterHockeyAppCrashReporting();
Current.DispatcherUnhandledException += Current_DispatcherUnhandledException;
}
private void Current_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
System.Environment.Exit(0);
}
private async void RegisterHockeyAppCrashReporting()
{
HockeyClient.Current.Configure(AppConstants.APP_ID)
.SetContactInfo(AppConstants.USER_NAME, AppConstants.USER_EMAIL);
await HockeyClient.Current.SendCrashesAsync(true);
}
}
MainWindow class:
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
private void Button_Click(object sender, RoutedEventArgs e)
{
var zero = 0;
var number = 1;
var crash = number / zero;
}
}
Environement.Exit terminates your application immediately. So, I guess, there's nothing strange in the fact that Hockey does not do anything.
Exit terminates an application immediately, even if other threads are
running. If the return statement is called in the application entry
point, it causes an application to terminate only after all foreground
threads have terminated.
If Exit is called from a try or catch block, the code in any finally
block does not execute. If the return statement is used, the code in
the finally block does execute.
Best practices tend to be opinion based and situation dependent. We, for example, log stack trace on unhandled exceptions and then call Environement.FailFast in our UWP app (we do not use Hockey apps though). Our logic is simple - our logger facility is probably alive but we're not so sure about the rest of the app. If even the logger facility is not functional than we won't be able to do anything anyway. Imho Exit and FailFast are the last steps that should only be used when you have no hope of restoring some valid state.
Here's a strange issue I'm facing with a Windows 8.1 XAML application.
A bug in DevExpress controls causes the entire application to crash, despite my implementation of exception handling. DevExpress developers have replicated this particular bug and are working on a solution - this question is about the crash despite error handling and NOT about the DevExpress bug.
The unique thing about this crash is that it breaks on this line in the auto-generated code in App.g.i.cs (as opposed to other exceptions being thrown in other places):
#if DEBUG && !DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
UnhandledException += (sender, e) =>
{
if (global::System.Diagnostics.Debugger.IsAttached) global::System.Diagnostics.Debugger.Break();
};
#endif
It seems this is triggered when some kind of exception / crash happens in XAML-related mechanisms (but this is just a wild guess on my part)... I don't think the above code is responsible for the "crash to desktop" effect, but it does seem to be a symptom.
My own code for error handling (in App.xaml.cs):
public App()
{
//...
this.UnhandledException += App_UnhandledException;
//...
}
private async void App_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
var ex = e.Exception;
e.Handled = true;
Logger.LoggingError(ex);
await Controls.MessageDialog.Show(ex.Message, Controls.MessageDialog.DialogType.Error, Controls.MessageDialog.DialogButtons.Retry, ElementTheme.Light);
var frame = Window.Current.Content as Frame;
frame.Navigate(typeof(Views.SplashLoading));
}
The error handling attempts to:
log the error
display the error
go back to the start view
Again - this generally works very well for all other purposes. But if ever the breakpoint in App.g.i.cs gets triggered (or would get triggered, if the application is released on client machines) then my error handling fails completely.
Note, that this isn't exclusive to DevExpress controls. It's just that the DevExpress control causes this behavior in a way that can be replicated. Again - if an exception would cause the code in App.g.i.cs be fired, then it seems there's no saving the application.
What could I do to make sure the application keeps going once this unfortunate event occurs and doesn't crash to the desktop?
EDIT:
For reference, this is the error message which occurs when using the DevExpress controls:
System.ArgumentException: The parameter is incorrect.
The value cannot be infinite or Not a Number (NaN).
at Windows.UI.Xaml.Controls.ScrollViewer.ChangeView(Nullable`1 horizontalOffset, Nullable`1 verticalOffset, Nullable`1 zoomFactor, Boolean disableAnimation)
at DevExpress.Core.Native.DXVirtualizingPanel.ScrollElementIntoView(Double elementOffset, Double rowHeight)
at DevExpress.Core.Native.DXVirtualizingPanel.ScrollIntoView(Int32 visibleIndex)
at DevExpress.UI.Xaml.Grid.DataControlBas
Unfortunately that's the full message - it appears the complete stack-trace is missing.
Apparently setting e.Handled = true; does not guarantee that the application won't crash (as described on MSDN):
The Windows Runtime considers exceptions encountered during certain
operations as nonrecoverable, because the Windows Runtime itself will
be in an inconsistent state following these exceptions. For such
exceptions, even if the UnhandledException event handler sets Handled
to true, the app will still be terminated.
However, why does the DevExpress cause such an invalid state with its control is a mystery to me... But at least it solves the question of why the app closes despite the event being handled.
Extra thanks goes to the folks from DevExpress support team, who helped with the case.
I am quite new to WPF but find AMAZING to be able to trap any unhandled exception. I have put
this.Dispatcher.UnhandledException += Dispatcher_UnhandledException;
in the constructor of my class. This leads me to trap it with
private void Dispatcher_UnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
e.Handled = true;
...
}
At first it didn't work but then I've seen that to make it work I have to run it in release and outside VS IDE. So that works.
What I'd like is to get as much as info as possible about what caused the exception. Possibly the exception type, the s/r, the line and whatever else is provided.
At the moment by doing
int a = 0;
int b = 3 / a;
and by putting
MessageBox.Show(e.ToString() + " " + sender.ToString());
I get:
so that's not the right way.
I know that I am not putting the necessary information in the question but I have searched through various answer but none reported what I need. If so it can be useful to save any data prior closing but not about closing but not to detected what caused the exception
What's more when I exit with
Environment.Exit(-1)
I find the process still running and that's a problem.
Here Terminate application after unhandled exception it says that I have to kill my process is it really the right way to close my application after an unhandled exception?
Thanks for any help
The actual exception that caused the application to crash is wrapped inside the DispatcherUnhandledExceptionEventArgs parameter.
Simply use e.Exception to get hold of it.
MessageBox.Show(e.Exception.ToString());
After displaying the exception, I would suggest allowing the application to continue by calling the base method:
base.OnUnhandledException(sender, e);
You may choose to mark the exception as handled of course, however in the case of when you are simply overriding this method to display the error, I would not count that as handled.
In my Windows Phone app I use Application.UnhandledException to catch all unhandled errors. If that kind of error happens then my app shows a simple MessageBox with a request to send an error report to developers via email. It looks like this:
protected virtual void OnUnhandledException(
object sender, ApplicationUnhandledExceptionEventArgs e)
{
Deployment.Current.Dispatcher.BeginInvoke(() =>
{
var result = MessageBox.Show(
"Would you like to send a report to developers?",
"Error",
MessageBoxButton.OKCancel);
if (result == MessageBoxResult.OK)
{
var task = new EmailComposeTask();
task.To = "feedback#site.com";
task.Subject = "Error";
task.Body =
e.ExceptionObject + "\n" + e.ExceptionObject.StackTrace;
task.Show();
e.Handled = true;
}
});
}
In most cases all works fine.
But many users complains that sometimes the app simply crashes with no messages. I have some crash reports in my developer's dashboard but these reports have a very small amount of useful information. And I can't understand what kind of error can cause this. I only have an assumption that some error happens in one of background threads.
Is Application.UnhandledException works properly in all cases? Could some exceptions stay unhandled? What can be done in situation described above?
Thanks.
In addition to the points in the other answers, you can't guarantee the Dispatcher is still running or that the UI thread will execute again.
Of course any attempt to do almost anything could fail if the app or OS is in a bad state (especially with OutOfMemory). So the less you do the better - that way you won't mess up the crash reports that the phone collects and uploads to the Store.
You should instead write the exception detail to IsolatedStorage and detect the presence of a past exception the next time you start your app.
Unhandled exceptions in worker threads or those scheduled by Task are not reported in the Application.UnhandledException, AFAIK.
Have a read at this: http://www.markermetro.com/2013/01/technical/handling-unhandled-exceptions-with-asyncawait-on-windows-8-and-windows-phone-8/, there seems to be a good approach to making sure you can catch those unhandled in async code.
Not all exceptions can be handled. Basically, all exceptions that may endanger the runtime stability won't be handled. By my experience, the most frequent one is the OutOfMemoryException.
We have a WPF application where parts of it may throw exceptions at runtime. I'd like to globally catch any unhandled exceptions and log them, but otherwise continue program execution as if nothing happened (kinda like VB's On Error Resume Next).
Is this possible in C#? And if so, where exactly would I need to put the exception handling code?
Currently I can't see any single point where I could wrap a try/catch around and which would catch all exceptions that could occur. Even then, I would have left whatever has been executed because of the catch. Or am I thinking in horribly wrong directions here?
ETA: Because many people below pointed it out: The application is not for controlling nuclear power plants. If it crashes, it's not that big a deal, but it throws random exceptions that are mostly UI-related that are a nuisance in the context where it would be used. There were (and probably still are) a few of those and since it uses a plugin architecture and may be extended by others (also students in that case; so no experienced developers that are able to write completely error-free code).
As for the exceptions that get caught: I do log them to a log file, including the complete stack trace. That was the whole point of that exercise. Just to counter those people that were taking my analogy to VB's OERN too literally.
I know that blindly ignoring certain classes of errors is dangerous and might corrupt my application instance. As said before, this program isn't mission-critical for anyone. No-one in their right mind would bet the survival of the human civilization on it. It's simply a little tool for testing certain design approaches wrt. software engineering.
For the immediate use of the application there are not many things that can happen on an exception:
No exception handling – error dialog and application exit. Experiment has to be repeated, though likely with another subject. No errors have been logged, which is unfortunate.
Generic exception handling – benign error trapped, no harm done. This should be the common case judged from all errors we were seeing during development. Ignoring this kind of errors should have no immediate consequences; the core data structures are tested well enough that they will easily survive this.
Generic exception handling – serious error trapped, possibly crash at a later point. This may happen rarely. We've never seen it so far. The error is logged anyway and a crash might be inevitable. So this is conceptually similar to the very first case, except that we have a stack trace. And in the majority of cases the user won't even notice.
As for the experiment data generated by the program: A serious error would at worst just cause no data to be recorded. Subtle changes that change the result of the experiment ever so slightly are pretty unlikely. And even in that case, if the results seem dubious the error was logged; one can still throw away that data point if it's a total outlier.
To summarize: Yes, I consider myself still at least partially sane and I don't consider a global exception handling routine which leaves the program running to be necessarily totally evil. As said twice before, such a decision might be valid, depending on the application. In this case it was judged a valid decision and not total and utter bullshit. For any other application that decision might look different. But please don't accuse me or the other people who worked on that project to potentially blow up the world just because we're ignoring errors.
Side note: There is exactly one user for that application. It's not something like Windows or Office that gets used by millions where the cost of having exceptions bubble to the user at all would be very different in the first place already.
Use the Application.DispatcherUnhandledException Event. See this question for a summary (see Drew Noakes' answer).
Be aware that there'll be still exceptions which preclude a successful resuming of your application, like after a stack overflow, exhausted memory, or lost network connectivity while you're trying to save to the database.
Example code using NLog that will catch exceptions thrown from all threads in the AppDomain, from the UI dispatcher thread and from the async functions:
App.xaml.cs :
public partial class App : Application
{
private static Logger _logger = LogManager.GetCurrentClassLogger();
protected override void OnStartup(StartupEventArgs e)
{
base.OnStartup(e);
SetupExceptionHandling();
}
private void SetupExceptionHandling()
{
AppDomain.CurrentDomain.UnhandledException += (s, e) =>
LogUnhandledException((Exception)e.ExceptionObject, "AppDomain.CurrentDomain.UnhandledException");
DispatcherUnhandledException += (s, e) =>
{
LogUnhandledException(e.Exception, "Application.Current.DispatcherUnhandledException");
e.Handled = true;
};
TaskScheduler.UnobservedTaskException += (s, e) =>
{
LogUnhandledException(e.Exception, "TaskScheduler.UnobservedTaskException");
e.SetObserved();
};
}
private void LogUnhandledException(Exception exception, string source)
{
string message = $"Unhandled exception ({source})";
try
{
System.Reflection.AssemblyName assemblyName = System.Reflection.Assembly.GetExecutingAssembly().GetName();
message = string.Format("Unhandled exception in {0} v{1}", assemblyName.Name, assemblyName.Version);
}
catch (Exception ex)
{
_logger.Error(ex, "Exception in LogUnhandledException");
}
finally
{
_logger.Error(exception, message);
}
}
AppDomain.UnhandledException Event
This event provides notification of uncaught exceptions. It allows the
application to log information about the exception before the system
default handler reports the exception to the user and terminates the
application.
public App()
{
AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);
}
static void MyHandler(object sender, UnhandledExceptionEventArgs args)
{
Exception e = (Exception) args.ExceptionObject;
Console.WriteLine("MyHandler caught : " + e.Message);
Console.WriteLine("Runtime terminating: {0}", args.IsTerminating);
}
If the UnhandledException event is handled in the default application
domain, it is raised there for any unhandled exception in any thread,
no matter what application domain the thread started in. If the thread
started in an application domain that has an event handler for
UnhandledException, the event is raised in that application domain. If
that application domain is not the default application domain, and
there is also an event handler in the default application domain, the
event is raised in both application domains.
For example, suppose a thread starts in application domain "AD1",
calls a method in application domain "AD2", and from there calls a
method in application domain "AD3", where it throws an exception. The
first application domain in which the UnhandledException event can be
raised is "AD1". If that application domain is not the default
application domain, the event can also be raised in the default
application domain.
In addition what others mentioned here, note that combining the Application.DispatcherUnhandledException (and its similars) with
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="1" />
</runtime>
</configuration>
in the app.config will prevent your secondary threads exception from shutting down the application.
Here is complete example using NLog
using NLog;
using System;
using System.Windows;
namespace MyApp
{
/// <summary>
/// Interaction logic for App.xaml
/// </summary>
public partial class App : Application
{
private static Logger logger = LogManager.GetCurrentClassLogger();
public App()
{
var currentDomain = AppDomain.CurrentDomain;
currentDomain.UnhandledException += CurrentDomain_UnhandledException;
}
private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
var ex = (Exception)e.ExceptionObject;
logger.Error("UnhandledException caught : " + ex.Message);
logger.Error("UnhandledException StackTrace : " + ex.StackTrace);
logger.Fatal("Runtime terminating: {0}", e.IsTerminating);
}
}
}
in Wpf application Project follow this Steps:
in App.xaml.cs file:
using 'System.Windows.Threading'
create App_DispatcherUnhandledException method same example.
example:
using System.Windows;
using System.Windows.Threading;
namespace Test
{
public partial class App : Application
{
void App_DispatcherUnhandledException(object sender,
DispatcherUnhandledExceptionEventArgs e)
{
// Process unhandled exception
// Prevent default unhandled exception processing
e.Handled = true;
}
}
}
in App.xaml:
add DispatcherUnhandledException="App_DispatcherUnhandledException"
for Example:
<Application x:Class="eValGr.UI.Light.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:eValGr.UI.Light"
DispatcherUnhandledException="Application_DispatcherUnhandledException">
<Application.Resources>
</Application.Resources>
</Application>
Like "VB's On Error Resume Next?" That sounds kind of scary. First recommendation is don't do it. Second recommendation is don't do it and don't think about it. You need to isolate your faults better. As to how to approach this problem, it depends on how you're code is structured. If you are using a pattern like MVC or the like then this shouldn't be too difficult and would definitely not require a global exception swallower. Secondly, look for a good logging library like log4net or use tracing. We'd need to know more details like what kinds of exceptions you're talking about and what parts of your application may result in exceptions being thrown.