How do I reliably capture *all* iOS exceptions in Xamarin? - xamarin

This link describes how to handle exceptions in iOS
Runtime.MarshalManagedException += (object sender, MarshalManagedExceptionEventArgs args) =>
{
Console.WriteLine ("Marshaling managed exception");
Console.WriteLine (" Exception: {0}", args.Exception);
Console.WriteLine (" Mode: {0}", args.ExceptionMode);
};
Runtime.MarshalObjectiveCException += (object sender, MarshalObjectiveCExceptionEventArgs args) =>
{
Console.WriteLine ("Marshaling Objective-C exception");
Console.WriteLine (" Exception: {0}", args.Exception);
Console.WriteLine (" Mode: {0}", args.ExceptionMode);
};
In addition, I've seen other Xamarin samples use this in the AppDelegate
AppDomain.CurrentDomain.UnhandledException += (sender, e) => {
try
{
var exception = ((Exception)e.ExceptionObject).GetBaseException();
Console.WriteLine("**SPORT UNHANDLED EXCEPTION**\n\n" + exception);
exception.Track();
}
catch
{
throw;
}
};
Question
What are the exception types (if more than Managed/Unmanaged), and how do I capture everything?

It goes without saying that a 'global' exception handler should not be a replacement for correctly catching expected or anticipated exceptions from blocks of code you anticipate to see issues with (perhaps because you use the parrallel libaries, or anything with any kind of thread complexity).
'global' exception handlers (in my opinion) should be used to catch anything you've failed to spot during development and testing. Personally I write these to a log file in our applications and handle them as 'Critical Exceptions' as they will cause the application to crash. My preferred method is to assign an event to 'AppDomain.CurrentDomain.UnhandledException'.
That being said during development, testing and if during production the users of your application happen to have 'diagnostic reporting' set to on you will be able to access apples exception logs. These can be useful but bear in mind they will give you the 'native' stack trace and won't have anything specific to xamarin in them. So take them with a pinch of salt.
as to your question, assigning to 'AppDomain.CurrentDomain.UnhandledException' will capture every exception that you haven't done or forseen yourself. you don't need to know the types explicitly as the stack trace will obviously tell you what they are. it's also worth noting that you can only use that event to record information or perform very basic functions as the app will close irrespective of what you do. So use it to log as much information regarding your application as possible.
It is currently impossible to stop your application from closing if it hits the unhandledexception event.

Related

Xamarin Android try/catch does not work with udp.SendAsync()

I've built a simple app that talks over UDP, to an endpoint at an IP the user specifies. It uses System.Net.Sockets.UdpClient, which works pretty well on Android - I'm able to send and receive packets fairly consistently. With one glaring exception... Exceptions. It seems to completely evade try/catch; my guess is the underlying implementation errors so hard that errors cannot be caught. For example:
UdpClient Udp { get; protected set; }
Udp.Connect("192.168.1.254"); // Any bad IP
try
{
int bytesSent = await udp.SendAsync(bytes, bytes.Length);
}
catch(Exception ex)
{
return null;
}
When testing on an actual Android device, any UDP traffic sent to a bad IP consistently destroys the application.
The behavior gets crazier. For example, if I put the call out on a background thread, with a nested try/catch, like this:
Task.Run(ping).ConfigureAwait(false);
protected async Task ping()
{
try
{
await checkIp();
}
catch(Exception ex)
{
}
}
Then there are some scenarios where I actually can get an Exception - but only in the outer catch! The throw occurs on the SendAsync call inside the inner try, but the inner catch misses it, landing only in the outer catch. The exception is a System.Net.Sockets.SocketException with type ConnectionRefused. Depending on how exactly I step through it, sometimes that gets caught there, sometimes not at all; when it's not at all, the app just implodes.
Is this expected behavior? Is Xamarin UdpClient just not supposed to be used? Bug? Better approach than SendAsync? Other?

Switch Screens in BlackBerry

I have a BlackBerry App that has a Listener for the Send Button implemented in the CheckIn Screen. Data is sent through a web service. If the data is sent successfully, a confirmation message of "OK" is received. I am trying to switch screens in my BlackBerry App depending on the response received.
FieldChangeListener sendBtnListener = new FieldChangeListener() {
public void fieldChanged(Field field, int context)
{
try {
String alertMsg=sendTextCheckIn();
if(alertMsg.equals("OK"))
{
UiApplication.getUiApplication().invokeLater( new Runnable()
{
public void run ()
{
UiApplication.getUiApplication().pushScreen(new MyScreen());
}
} );
}
} catch (UnsupportedEncodingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
};
However, the above is throwing an App Error 104: IllegalStateException. Can anyone please guide on how to switch screens between a BlackBerry App.
EDIT: I can switch to any other screen but I CAN NOT switch to MyScreen. NOTE: MyScreen is the main (first) screen of the App. The above method sendTextCheckIn() calls another method that is placed inside MyScreen. Has this got anything to do with the error? Please advice.
The 'fieldChanged' event is already running on the UI event thread, so you shouldn't need to do the invokeLater call within it, just call pushScreen directly.
You mention that your problem with IllegalStateException only happens for MyScreen. That makes it sound like something specific with the implementation of MyScreen. Start narrowing down the problem - look at what happens in the constructor of MyScreen, and any events that might get called before the screen is visible. Some of that code is what is causing the problem.
Wrap everything that could possibly raise in exception in try/catch.
Don't do e.printStackTrace() - that won't give you much.
Instead do something like System.err.println ("KABOOM in method abc() - " + e); - seems like more effort, but trust me, that becomes INVALUABLE when debugging issues like this.
Catch Exception, unless you have a VERY good reason to catch a specific a subtype - otherwise you WILL end up with unexpected, and uncaught exceptions, which you will hunt for DAYS.

Is it possible to change DesiredAccuracy & ReportInterval of Geolocator in PositionChanged Event handler?

I want to change the DesiredAccuracy and ReportInterval in PositionChanged Event Handler, so that I can dynamically change the position update frequency at different locations.
I did something like this,
void geolocator_PositionChanged(Geolocator sender, PositionChangedEventArgs args)
{
geolocator.StatusChanged -= geolocator_StatusChanged;
geolocator.PositionChanged -= geolocator_PositionChanged;
geolocator.DesiredAccuracy = PositionAccuracy.High;
geolocator.ReportInterval = 5 * 1000;
geolocator.StatusChanged += geolocator_StatusChanged;
geolocator.PositionChanged += geolocator_PositionChanged;
}
But the problem is I got
$exception {System.Exception: Operation aborted (Exception from HRESULT: 0x80004004 (E_ABORT))
at
Windows.Devices.Geolocation.Geolocator.put_DesiredAccuracy(PositionAccuracy
value)
I do not understand this exception because it doesn't state the reason.
How can I achieve this (to change the accuracy & reporting interval dynamically)?
Thanks.
According to this Microsoft article, your exception indicates that you've disabled the location service from your phones setting:
catch (Exception ex)
{
if ((uint)ex.HResult == 0x80004004)
{
// the application does not have the right capability or the location master switch is off
StatusTextBlock.Text = "location is disabled in phone settings.";
}
//else
{
// something else happened acquring the location
}
}
It might be best if you move to using GeoCoordinateWatcher and invoke Stop()/Start() before changing these properties. There are a few advantages to use GeoLocator over GeoCoordinateWatcher, but nothing critical for most apps. Since GeoCoordinateWatcher is still fully supported on WP8 it might just be easier on you to switch to it if that's feasible.
As you already did in your code, removing all handlers of StatusChanged and PositionChanged is required to be able to modify ReportInterval etc. Otherwise this exception (0x80004004) will be thrown.
In my case, removing all handlers was not an option because i'm using the Geolocator in the my WP8 app to keep my app alive in background. Removing the last handler will also suspend my app because, from WP's point of view, there's no reason to keep the app alive in background.
I found out that it is possible to overcome this problem by creating a temporary Geolocator:
// Wire up a temporary Geolocator to prevent the app from closing
var tempGeolocator = new Geolocator
{
MovementThreshold = 1,
ReportInterval = 1
};
TypedEventHandler<Geolocator, PositionChangedEventArgs> dummyHandler = (sender, positionChangesEventArgs2) => { };
tempGeolocator.PositionChanged += dummyHandler;
Geolocator.PositionChanged -= OnGeolocatorOnPositionChanged;
Geolocator.ReportInterval = reportInterval;
Geolocator.PositionChanged += OnGeolocatorOnPositionChanged;
tempGeolocator.PositionChanged -= dummyHandler;
This way the app will not be killed by WP. Keep in mind that rebinding the PositionChanged will also cause an immediate callback.

Getting an Unhandled Exception in VS2010 debugger even though the exception IS handled

I have an issue with VS2010 where the debugger stops with an Unhandled Exception. However, the exception is definitely handled. In fact, if I put code in the catch block, I'll hit it when I press F5. In Debug -> Exceptions, I definitely do not have the "Thrown" checkbox checked, so IMO there is absolutely no reason for the unhandled exception dialog to pop up...
I can't post the exact code, but will work on a sample soon. The basic idea behind the offending code section is that I have a thread that talks to hardware, and if I have an error talking to it, then I throw a HardwareException. The thread is launched with BeginInvoke, and the exception is caught in the callback handler when I call EndInvoke.
When the exception is thrown in the debugger, I get a messagebox that says 'HardwareException not handled by user code". But it is!!!
EDIT -- Well, this is driving me crazy. I've got sample code that is representative of the code I have in my application, and it looks like this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.Remoting.Messaging;
using System.Threading;
namespace ConsoleApplication1
{
public class HardwareException : ApplicationException
{
public HardwareException( string message) : base(message) {}
}
class Program
{
delegate void HardwareTestDelegate();
static void Main(string[] args)
{
HardwareTestDelegate d = new HardwareTestDelegate( HardwareTestThread);
d.BeginInvoke( HardwareTestComplete, null);
while( true);
}
static void HardwareTestThread()
{
throw new HardwareException( "this is a test");
}
static void HardwareTestComplete( IAsyncResult iar)
{
try {
AsyncResult ar = (AsyncResult)iar;
HardwareTestDelegate caller = (HardwareTestDelegate)ar.AsyncDelegate;
caller.EndInvoke( iar);
} catch( Exception ex) {
Console.WriteLine( "Should see this line without getting an unhandled exception message in the IDE");
}
}
}
}
I throw my HardwareException from the thread, and then handle the exception when EndInvoke is called. I guess Murphy was right, because when I run this sample code, it does what I expect -- i.e. no unhandled exception error message pops up in the IDE!
Here is the response from Microsoft, case 111053102422121. Allen Weng writes the following:
Analysis:
For your information, CLR will re-throw the exception inside the callback when you call EndInvoke(). Below is a simplified version of EndInvoke():
public object EndInvoke(IAsyncResult asyncResult)
{
using (new MultithreadSafeCallScope())
{
ThreadMethodEntry entry = asyncResult as ThreadMethodEntry;
............
if (entry.exception != null)
{
throw entry.exception;
}
}
}
The exception will be handled in the call back function or in the asynchronous method if an exception handler is provided. This is how it works without a debugger attached.
When you run it in VS.NET, the debugger seems checking only the presence of the exception handler in the asynchronous method. If there is no such handler, the debugger would think the exception is not handled and pop up an error message notifying you of this.
Suggestion:
The application should work as expected when you run it stand alone. If the error message is annoying in debugging for you, you can disable it by unchecking “User unhandled” for “Common Language Runtime Exceptions”in the Exception dialog box (Debug|Exceptions or press CTRL+ATL+E). Or you can add try/catch in the asynchronous method. In the latter case, the exception is set to null and won’t be re-thrown in EndInvoke().
I'm having this same problem, so I'll post this possible workaround for posterity's sake:
In your code that throws an exception into the .NET code (HardwareTestThread() in the example above,) catch the exception that's being thrown and wrap it in some esoteric .NET exception type for which you can disable the "user-unhandled" option in the Debug>Exceptions dialog. For my case, I needed to allow an IOException to propagate through some .NET code back to my code, so I just caught the IOException and wrapped in an AppDomainUnloadedException before letting it propagate through the .NET code back to my catch block. I chose AppDomainUnloadedException because user-unhandled is unchecked for it by default and it's in the System.dll assembly, so it was already being imported in my project, though any exception should work, so long as you disable the "user-unhandled" option for it and you don't care that the debugger won't break on that type of exception in the future.
Here's my code that wraps the IOException I was needing to propagate:
public override int Read(byte[] buffer, int offset, int count)
{
try { return innerStream.Read(buffer, offset, count); }
catch (IOException ex) { throw new AppDomainUnloadedException("Exception from innerStream: " + ex.Message, ex); }
}
And here's my code where I'm catching it on the other side of the .NET code it needed to propagate through:
try { bytesRead = sslStream.Read(buffer, offset, count); }
catch (Exception ex) { /* ex handled here. */ }

Visual Studio: How to break on handled exceptions?

I would like Visual Studio to break when a handled exception happens (i.e. I don't just want to see a "First chance" message, I want to debug the actual exception).
e.g. I want the debugger to break at the exception:
try
{
System.IO.File.Delete(someFilename);
}
catch (Exception)
{
//we really don't care at runtime if the file couldn't be deleted
}
I came across these notes for Visual Studio.NET:
1) In VS.NET go to the Debug Menu >>
"Exceptions..." >> "Common Language
Runtime Exceptions" >> "System" and
select "System.NullReferenceException"
2) In the bottom of that dialog there
is a "When the exception is thrown:"
group box, select "Break into the
debugger"
3) Run your scenario. When the
exception is thrown, the debugger will
stop and notify you with a dialog that
says something like:
"An exception of type "System.NullReferenceException" has
been thrown.
[Break] [Continue]"
Hit [Break]. This will put you on the
line of code that's causing the
problem.
But they do not apply to Visual Studio 2005 (there is no Exceptions option on the Debug menu).
Does anyone know where the find this options dialog in Visual Studio that the "When the exception is thrown" group box, with the option to "Break into the debugger"?
Update: The problem was that my Debug menu didn't have an Exceptions item. I customized the menu to manually add it.
With a solution open, go to the Debug - Windows - Exception Settings (Ctrl+Alt+E) menu option. From there you can choose to break on Thrown or User-unhandled exceptions.
EDIT: My instance is set up with the C# "profile" perhaps it isn't there for other profiles?
There is an 'exceptions' window in VS2005 ... try Ctrl+Alt+E when debugging and click on the 'Thrown' checkbox for the exception you want to stop on.
Took me a while to find the new place for expection settings, therefore a new answer.
Since Visual Studio 2015 you control which Exceptions to stop on in the Exception Settings Window (Debug->Windows->Exception Settings). The shortcut is still Ctrl-Alt-E.
The simplest way to handle custom exceptions is selecting "all exceptions not in this list".
Here is a screenshot from the english version:
Here is a screenshot from the german version:
From Visual Studio 2015 and onward, you need to go to the "Exception Settings" dialog (Ctrl+Alt+E) and check off the "Common Language Runtime Exceptions" (or a specific one you want i.e. ArgumentNullException) to make it break on handled exceptions.
Step 1
Step 2
Check Managing Exceptions with the Debugger page, it explains how to set this up.
Essentially, here are the steps (during debugging):
On the Debug menu, click Exceptions.
In the Exceptions dialog box, select Thrown for an entire category of exceptions, for example, Common Language Runtime Exceptions.
-or-
Expand the node for a category of exceptions, for example, Common Language Runtime Exceptions, and select Thrown for a specific exception within that category.
A technique I use is something like the following. Define a global variable that you can use for one or multiple try catch blocks depending on what you're trying to debug and use the following structure:
if(!GlobalTestingBool)
{
try
{
SomeErrorProneMethod();
}
catch (...)
{
// ... Error handling ...
}
}
else
{
SomeErrorProneMethod();
}
I find this gives me a bit more flexibility in terms of testing because there are still some exceptions I don't want the IDE to break on.
The online documentation seems a little unclear, so I just performed a little test. Choosing to break on Thrown from the Exceptions dialog box causes the program execution to break on any exception, handled or unhandled. If you want to break on handled exceptions only, it seems your only recourse is to go through your code and put breakpoints on all your handled exceptions. This seems a little excessive, so it might be better to add a debug statement whenever you handle an exception. Then when you see that output, you can set a breakpoint at that line in the code.
There are some other aspects to this that need to be unpacked. Generally, an app should not throw exceptions unless something exceptional happens.
Microsoft's documentation says:
For conditions that are likely to occur but might trigger an exception, consider handling them in a way that will avoid the exception.
and
A class can provide methods or properties that enable you to avoid making a call that would trigger an exception.
Exceptions degrade performance and disrupt the debugging experience because you should be able to break on all exceptions in any running code.
If you find that your debugging experience is poor because the debugger constantly breaks on pointless exceptions, you may need to detect handled exceptions in your tests. This technique allows you to fail tests when code throws unexpected exceptions.
Here are some helper functions for doing that
public class HandledExceptionGuard
{
public static void DoesntThrowException(Action test,
Func<object?, Exception, bool>? ignoreException = null)
{
var errors = new List<ExceptionInformation>();
EventHandler<FirstChanceExceptionEventArgs> handler = (s, e) =>
{
if (e.Exception is AssertFailedException) return;
if (ignoreException?.Invoke(s, e.Exception) ?? false) return;
errors.Add(new ExceptionInformation(s, e.Exception, AppDomain.CurrentDomain.FriendlyName));
};
AppDomain.CurrentDomain.FirstChanceException += handler;
test();
AppDomain.CurrentDomain.FirstChanceException -= handler;
if (errors.Count > 0)
{
throw new ExceptionAssertionException(errors);
}
}
public async static Task DoesntThrowExceptionAsync(Func<Task> test,
Func<object?, Exception, bool>? ignoreException = null)
{
var errors = new List<ExceptionInformation>();
EventHandler<FirstChanceExceptionEventArgs> handler = (s, e) =>
{
if (e.Exception is AssertFailedException) return;
if (ignoreException?.Invoke(s, e.Exception) ?? false) return;
errors.Add(new ExceptionInformation(s, e.Exception, AppDomain.CurrentDomain.FriendlyName));
};
AppDomain.CurrentDomain.FirstChanceException += handler;
await test();
AppDomain.CurrentDomain.FirstChanceException -= handler;
if (errors.Count > 0)
{
throw new ExceptionAssertionException(errors);
}
}
}
If you wrap any code in these methods as below, the test will fail when a handled exception occurs. You can ignore exceptions with the callback. This validates your code against unwanted handled exceptions.
[TestClass]
public class HandledExceptionTests
{
private static void SyncMethod()
{
try
{
throw new Exception();
}
catch (Exception)
{
}
}
private static async Task AsyncMethod()
{
try
{
await Task.Run(() => throw new Exception());
}
catch (Exception)
{
}
}
[TestMethod]
public void SynchronousTest()
{
HandledExceptionGuard.DoesntThrowException(() => SyncMethod());
}
[TestMethod]
public async Task AsyncTest()
{
await HandledExceptionGuard.DoesntThrowExceptionAsync(() => AsyncMethod());
}
}

Resources