Can you prevent exceptions on Xamarin.Mac from terminating the app? - xamarin

I know that catching all exceptions in an app is generally bad, but in my WPF app I do:
Application.Current.DispatcherUnhandledException += (s, e) => {
ReportException(e.Exception, false);
e.Handled = true;
};
This is mostly useful to prevent minor features (like drag&drop) and async code from crashing the app - I log & display the info to the user.
I want to do the same thing in Xamarin.Mac, but there doesn't seem to be an equivalent. I tried:
AppDomain.CurrentDomain.UnhandledException += (sender, args) => Log(args.Exception);
TaskScheduler.UnobservedTaskException += (sender, args) =>
{
args.SetObserved();
Log(args.Exception);
};
Runtime.MarshalManagedException += (sender, args) => Log(args.Exception);
Runtime.MarshalObjectiveCException += (sender, args) => Log(args.Exception);
But when crashing in an async void method, TaskScheduler.UnobservedTaskException, MarshalManagedException and MarshalObjectiveCException are not called,
and AppDomain.Current.UnhandledException's e.IsTerminating is get-only, so I can't prevent the app from exiting.
For Android there's AndroidEnvironment.UnhandledExceptionRaiser += AndroidEnvironmentOnUnhandledException;
But for Mac there doesn't seem to be a way to cancel the app going down?

Unlike Javascript, native MacOS/iOS development is not exception safe and discourages recovering from exceptions as stated in Native iOS docs here:
The standard Cocoa convention is that exceptions signal programmer error and are not intended to be recovered from. Making code exceptions-safe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions safety. Therefore, ARC-generated code leaks by default on exceptions, which is just fine if the process is going to be immediately terminated anyway. Programs which do care about recovering from exceptions should enable the option.
There is a way of rejecting exceptions from being thrown by adding a command during compile time, as it is stated in the same link above.
Unfortunately, since Xamarin is Native development, you are stuck to the limitations of native development. The solution is really not to allow exceptions being raised in programming, by using comparisons if (x != null) or functions like TryParse, and to only use try-catch in the highest level when absolutely needed.
So even if you try, as shown here, you will not be able to prevent a crash, but you can add logs before the app will certainly crash. Here's another good resource for this, that explains it for native developers.

Related

How do I deal with a possible exception in a Xamarin Forms application deployed to iOS or Android?

I have a finished application which I would like to make available to run on the iOS and Android platforms.  I have tested the application as much as possible and it works without problem.  But I know there is always the chance that something might go wrong and I could get an exception.
My question is how can I deal with this or what should I do. What happens on the phone, if a Forms application is deployed and there is an exception.
Would appreciate any advice or even links as to how this is handled.
If an exception is thrown and not handled by your code, the app will stop working (i.e. crash).
In order to handle these crashes we are using MS AppCenter (the successor to HockeyApp/Xamarin AppInsights).
You'll have to create a project there (one for each platform), and add the NuGet package to your projects. Afterwards you can initialize it with
AppCenter.Start("ios={Your App Secret};android={Your App Secret}",
typeof(Crashes)); // you'll get the app secrets from appcenter.ms
Crashes will be logged to AppCenter now and you'll be informed whenever there is a new crash.
Please note that it's best practice (if not required by law), that you ask the user for consent before sending the crash report (see here). You are using the delegate Crashes.ShouldAwaitUserConfirmation for that matter. You could for example show an action sheet with Acr.UserDialogs
private bool AwaitUserConfirmation()
{
// you should of course use your own strings
UserDialogs.Instance.ActionSheet(
new ActionSheetConfig
{
Title = "Oopsie",
Message = "The app crashed. Send crash to developers.",
Options = new List<ActionSheetOption>
{
new ActionSheetOption("Sure", () => Crashes.NotifyUserConfirmation(UserConfirmation.Send)),
new ActionSheetOption("Yepp, and don't bug be again.", () => Crashes.NotifyUserConfirmation(UserConfirmation.AlwaysSend)),
new ActionSheetOption("Nope", () => Crashes.NotifyUserConfirmation(UserConfirmation.DontSend))
}
});
return true;
}

How to prevent app from crashing on uncaughtErrorEvent

Is there a way to prevent the app from crashing when JS uncaught errors occur?
Already tried to wrap app.start(...) inside try/catch, but it sure doesn't work:)
There is indeed, you can register an uncaughtErrorEvent listener.
Refer to the official documentation - https://docs.nativescript.org/core-concepts/application-lifecycle#use-application-events
You can drop the following in your app.js before bootstrapping the application
var application = require("application");
application.on(application.uncaughtErrorEvent, function (args) {
if (args.android) {
// For Android applications, args.android is an NativeScriptError.
console.log("NativeScriptError: " + args.android);
} else if (args.ios) {
// For iOS applications, args.ios is NativeScriptError.
console.log("NativeScriptError: " + args.ios);
}
});
There's no way to prevent the app from crashing. You can catch the error in the uncaughtError application event but the app will crash afterwards regardless.
Attempting to navigate to an error page won't work.
According to the comments on this GitHub issue:
Ability to specify custom error pages on uncaughtErrors · Issue #1718 · NativeScript/NativeScript
there is a way to customize the error page shown, but only on Android. Apparently there isn't anything similar available for iOS.
This is an older question but there is a documented way to prevent this using Nativescript older than 4.2 (you should be on 6+ now)
Disable rethrowing of uncaught js exceptions to native
Basically, catch the JS errors but do not crash the native app.
Note the disclaimer there as well. The script will be unstable at this point. Yes, it did not crash, but wherever it dies did not continue, so you might be worse off for stability. Putting the app in a bad state or just quitting/recrashing might be safer.

Error while leaving my application xamarin forms android in the background

My solution when I leave the application or leave it in the background gives an error 'The test application stopped', I can not find out where this queue comes from. Does anyone know where this trigger comes from the moment it leaves in the background
Is it something in this part of the code?
protected override void OnStart()
{
Debug.WriteLine("OnStart");
}
protected override void OnResume()
{
Debug.WriteLine("OnResume");
}
protected override void OnSleep()
{
Debug.WriteLine("OnSleep");
}
This type of errors came along with a specific part of your code, like #apineda mentioned maybe you are using an Android service that is updating some data on your application or it may be there to show a local notification who knows? but the thing I want to imply is that you need to take a look at your code and investigate further which is the part that is making the crash. Here are some tips:
1.- If you are using push notifications that may lead to something!
2.- Check you MainActivity.cs class since this is the one responsible of the Xamarin.Forms activity life cycle.
3.- If you have any timers on your shared code or even a background Task created with Task.Run or a Task.Factory.StartNew() check those too, deadlocks on Xamarin.Forms applications between the UI thread and background threads are a common thing on Xamarin.Forms.
I hope this helps!

How to debug a plugin in on-line version?

I've created a plugin and registered it using hte registration tool. I've also added a step that is supposed to handle a message of creation of an instance. Sadly, the intended behavior doesn't occur.
My guess is that something inside the plugin crashes but I have no idea on how to debug it. Setting up breakpoints is not going to work agains on-line version, I understand, so I'm not even trying.
For legal and technical reasons, I won't be able to lift over the solution to an on-premise installation, neither. Is guessing my only option?
For server-side (plugins) I'm using ITracingService. For client-side I log everything to console. The downside with the first is that you actually need to crash the execution to get to see anything. The downside with the latter is that plugins sometimes get executed without GUI being invoked at all.
When it comes to heavier projects, I simply set up a WCF web service that I call from the plugin and write to that. That way, on one screen, I'm executing the plugin while on the other, I'm getting a nice log file (or just put the sent information to on the screen).
You could, for instance, start with a very basic update of a field on the instance of your entity that's being created. When you have that working, you can always fall back to the last working version. If you don't even get that to work, it mean, probably, that you're setting up the plugin registration incorrectly.
A very efficient way would be to lift over the solution to an on-premise version where you have full control but I see in your question that it's not en option.
In case you could lift the solution to an on-premise version, here's a link on how to debug plugins.
Don't forget that you also have access to the ITracingService.
You can get a reference to it in your Execute method and then write to it every so often in your code to log variables or courses of action that you are attempting or have succeeded with. You can also use it to surface more valuable information when an exception occurs.
It's basically like writing to a console. Then, if anything causes the plug-in to crash at runtime then you can see everything that you've traced when you click Download Log File on the error shown to the user.
Beware though - unless your plug-in actually throws an exception (deliberate or otherwise) then you have no access to whatever was traced.
Example:
public void Execute(IServiceProvider serviceProvider)
{
// Obtain the execution context from the service provider.
IPluginExecutionContext context =
(IPluginExecutionContext)serviceProvider.GetService(
typeof(IPluginExecutionContext));
// Get a reference to the tracing service.
ITracingService tracingService =
(ITracingService)serviceProvider.GetService(typeof(ITracingService));
try
{
tracingService.Trace("Getting entity from InputParameters...");
// may fail for some messages, since "Target" is not present
var myEntity = (Entity)context.InputParameters["Target"];
tracingService.Trace("Got entity OK");
// some other logic here...
}
catch (FaultException<OrganizationServiceFault> ex)
{
_trace.Trace(ex.ToString());
while (ex.InnerException != null)
{
ex = (FaultException<OrganizationServiceFault>)ex.InnerException;
_trace.Trace(ex.ToString());
}
throw new InvalidPluginExecutionException(
string.Format("An error occurred in your plugin: {0}", ex));
}
catch (Exception ex)
{
_trace.Trace(ex.ToString());
while (ex.InnerException != null)
{
ex = ex.InnerException;
_trace.Trace(ex.ToString());
}
throw;
}
}

Can Visual Studio Test projects cope with events and delegates?

I am working on new functionality for a large C# project which is mostly legacy code.
The area that I'm working on handles XML schema messages, creates a schedule for their transmission and places them into some legacy timer code which notifies me when they should be sent.
Although I am new to them, Visual Studio test projects are proving useful in that I can test my code without trying to get the full system up and running (which can take upto 30 minutes on the test hardware!).
I have statically tested my event handling code, but would now like to do so dynamically.
Is this possible? If so how do I go about getting the test project to wait for the event without timing out?
If I understand you correctly, you could use a wait handle to signal the event and have your test project wait for the event handle to be signaled.
void Foo()
{
var eventSource = ...;
var waitHandle = new ManualResetEvent(false);
eventSource.SomeEvent += (sender, e) => waitHandle.Set();
...
// Wait for the event to be fired.
waitHandle.WaitOne();
}

Resources