Crashes on Android that aren't crashes
gauche
Posted on
Apr 20 2017
Hi,
I've been investigating an issue we're experiencing on Android where failed HTTP requests are resulting in crash reports. Here's an example crash report:
{
"MachineName": "Unknown",
"Version": "703 / 1.6.0.703",
"Error": {
"Data": {},
"ClassName": "Java.IO.IOException",
"Message": "Unable to resolve host \"api.foo\": No address associated with hostname",
"StackTrace": [
{
"LineNumber": 0,
"ClassName": "System.Runtime.ExceptionServices.ExceptionDispatchInfo",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "Throw()"
},
{
"LineNumber": 0,
"ClassName": "Java.Interop.JniEnvironment+InstanceMethods",
"FileName": "<f1d7be25f867425fa1a41173c85beadc>",
"MethodName": "CallVoidMethod(Java.Interop.JniObjectReference instance, Java.Interop.JniMethodInfo method, Java.Interop.JniArgumentValue* args)"
},
{
"LineNumber": 0,
"ClassName": "Java.Interop.JniPeerMembers+JniInstanceMethods",
"FileName": "<f1d7be25f867425fa1a41173c85beadc>",
"MethodName": "InvokeAbstractVoidMethod(System.String encodedMember, Java.Interop.IJavaPeerable self, Java.Interop.JniArgumentValue* parameters)"
},
{
"LineNumber": 0,
"ClassName": "Javax.Net.Ssl.HttpsURLConnectionInvoker",
"FileName": "<42a3166d43564b4b816191297740543d>",
"MethodName": "Connect()"
},
{
"LineNumber": 0,
"ClassName": "Java.Net.URLConnection",
"FileName": "<42a3166d43564b4b816191297740543d>",
"MethodName": "<ConnectAsync>m__0()"
},
{
"LineNumber": 0,
"ClassName": "System.Threading.Tasks.Task",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "InnerInvoke()"
},
{
"LineNumber": 0,
"ClassName": "System.Threading.Tasks.Task",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "Execute()"
},
{
"LineNumber": 0,
"FileName": "--- End of stack trace from previous location where exception was thrown ---"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.ExceptionServices.ExceptionDispatchInfo",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "Throw()"
},
{
"LineNumber": 0,
"ClassName": "Java.Interop.JniEnvironment+InstanceMethods",
"FileName": "<f1d7be25f867425fa1a41173c85beadc>",
"MethodName": "CallIntMethod(Java.Interop.JniObjectReference instance, Java.Interop.JniMethodInfo method, Java.Interop.JniArgumentValue* args)"
},
{
"LineNumber": 0,
"ClassName": "Java.Interop.JniPeerMembers+JniInstanceMethods",
"FileName": "<f1d7be25f867425fa1a41173c85beadc>",
"MethodName": "InvokeVirtualInt32Method(System.String encodedMember, Java.Interop.IJavaPeerable self, Java.Interop.JniArgumentValue* parameters)"
},
{
"LineNumber": 0,
"ClassName": "Java.Net.HttpURLConnection",
"FileName": "<42a3166d43564b4b816191297740543d>",
"MethodName": "get_ResponseCode()"
},
{
"LineNumber": 0,
"ClassName": "Xamarin.Android.Net.AndroidClientHandler+<DoProcessRequest>c__async1+<DoProcessRequest>c__AnonStorey5",
"FileName": "<42a3166d43564b4b816191297740543d>",
"MethodName": "<>m__1()"
},
{
"LineNumber": 0,
"ClassName": "System.Threading.Tasks.Task`1[TResult]",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "InnerInvoke()"
},
{
"LineNumber": 0,
"ClassName": "System.Threading.Tasks.Task",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "Execute()"
},
{
"LineNumber": 0,
"FileName": "--- End of stack trace from previous location where exception was thrown ---"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.ExceptionServices.ExceptionDispatchInfo",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "Throw()"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "ThrowForNonSuccess(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "ValidateEnd(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter[TResult]",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "GetResult()"
},
{
"LineNumber": 0,
"ClassName": "Xamarin.Android.Net.AndroidClientHandler+<DoProcessRequest>c__async1",
"FileName": "<42a3166d43564b4b816191297740543d>",
"MethodName": "MoveNext()"
},
{
"LineNumber": 0,
"FileName": "--- End of stack trace from previous location where exception was thrown ---"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.ExceptionServices.ExceptionDispatchInfo",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "Throw()"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "ThrowForNonSuccess(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "ValidateEnd(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter`1[TResult]",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "GetResult()"
},
{
"LineNumber": 0,
"ClassName": "Xamarin.Android.Net.AndroidClientHandler+<SendAsync>c__async0",
"FileName": "<42a3166d43564b4b816191297740543d>",
"MethodName": "MoveNext()"
},
{
"LineNumber": 0,
"FileName": "--- End of stack trace from previous location where exception was thrown ---"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.ExceptionServices.ExceptionDispatchInfo",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "Throw()"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "ThrowForNonSuccess(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "ValidateEnd(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter[TResult]",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "GetResult()"
},
{
"LineNumber": 0,
"ClassName": "Fusillade.RateLimitedHttpMessageHandler+<SendAsync>c__AnonStorey0+<SendAsync>c__async4",
"FileName": "<0edf88feb20d4057aae292cf3a0697e5>",
"MethodName": "MoveNext()"
},
{
"LineNumber": 0,
"FileName": "--- End of stack trace from previous location where exception was thrown ---"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.ExceptionServices.ExceptionDispatchInfo",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "Throw()"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "ThrowForNonSuccess(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.TaskAwaiter",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "ValidateEnd(System.Threading.Tasks.Task task)"
},
{
"LineNumber": 0,
"ClassName": "System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter[TResult]",
"FileName": "<91129971945a4b6882fe7059426d6f81>",
"MethodName": "GetResult()"
},
{
"LineNumber": 0,
"ClassName": "System.Net.Http.HttpClient+<SendAsyncWorker>c__async0",
"FileName": "<11c4ee9ae5b14a4d9d88ff775de793a8>",
"MethodName": "MoveNext()"
},
{
"LineNumber": 0,
"FileName": "--- End of managed Java.IO.IOException stack trace ---"
},
{
"LineNumber": 0,
"FileName": "java.net.UnknownHostException: Unable to resolve host \"api.foo\": No address associated with hostname"
},
{
"LineNumber": 0,
"ClassName": "java.net.InetAddress",
"MethodName": "lookupHostByName(InetAddress.java:440)"
},
{
"LineNumber": 0,
"ClassName": "java.net.InetAddress",
"MethodName": "getAllByNameImpl(InetAddress.java:252)"
},
{
"LineNumber": 0,
"ClassName": "java.net.InetAddress",
"MethodName": "getAllByName(InetAddress.java:215)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.Network$1",
"MethodName": "resolveInetAddresses(Network.java:29)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.http.RouteSelector",
"MethodName": "resetNextInetSocketAddress(RouteSelector.java:220)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.http.RouteSelector",
"MethodName": "nextProxy(RouteSelector.java:176)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.http.RouteSelector",
"MethodName": "next(RouteSelector.java:108)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.http.HttpEngine",
"MethodName": "createNextConnection(HttpEngine.java:482)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.http.HttpEngine",
"MethodName": "nextConnection(HttpEngine.java:465)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.http.HttpEngine",
"MethodName": "connect(HttpEngine.java:447)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.http.HttpEngine",
"MethodName": "sendRequest(HttpEngine.java:353)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.huc.HttpURLConnectionImpl",
"MethodName": "execute(HttpURLConnectionImpl.java:476)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.huc.HttpURLConnectionImpl",
"MethodName": "connect(HttpURLConnectionImpl.java:118)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.huc.DelegatingHttpsURLConnection",
"MethodName": "connect(DelegatingHttpsURLConnection.java:89)"
},
{
"LineNumber": 0,
"ClassName": "com.android.okhttp.internal.huc.HttpsURLConnectionImpl",
"MethodName": "connect(HttpsURLConnectionImpl.java:25)"
}
]
},
"Environment": {
"ProcessorCount": 8,
"OSVersion": "23",
"WindowBoundsWidth": 1440,
"WindowBoundsHeight": 2560,
"CurrentOrientation": "Rotation 0 (Portrait)",
"Architecture": "arm64-v8a",
"Model": "SM-G920I / samsung",
"TotalPhysicalMemory": 24963296,
"AvailablePhysicalMemory": 7867440,
"DeviceManufacturer": "samsung",
"UtcOffset": 10,
"Locale": "English (Australia)"
},
"Client": {
"Name": "Raygun4Net.Xamarin.Android",
"Version": "5.4.0.0",
"ClientUrl": "https://github.com/MindscapeHQ/raygun4net"
},
"User": {
"Identifier": "c296072b4c5dbdfa",
"IsAnonymous": true
},
"OccurredOn": "2017-04-20T00:00:24.212126Z"
}
Turns out, I can easily reproduce the issue by putting my device in flight mode and instigating a request. In reality, I suspect what's happening is users are losing connectivity momentarily and the app's data refreshes are "failing".
But the thing is, the app is not crashing. It's just a HTTP request failing, and the failure is being observed and logged. i.e. it's an expected failure that the app is handling gracefully. But for some reason Raygun is treating it as a crash.
I boiled this down to something very simple to prove that it's not something in my code. Here's what I put in my startup view model:
// in my VM constructor
this
.DoItAsync(httpClient)
.ContinueWith(
result =>
{
result.Exception.Handle(ex =>
{
logger.Warn(ex, "Request failed");
return true;
});
},
TaskContinuationOptions.OnlyOnFaulted);
private Task<HttpResponseMessage> DoItAsync(HttpClient httpClient)
{
var request = new HttpRequestMessage(HttpMethod.Get, "this/does/not/matter");
return httpClient
.SendAsync(request);
}
If I run this with my device in flight mode, the ContinueWith call is executed and the details of the exception are logged. But then Raygun kicks in and treats it as a crash, sending that same exception up to Crash Reporting.
What is going on here?
Thanks
gauche
Posted on
Apr 26 2017
Bump. Can I get a response to this please?
Jason Fauchelle
Raygun
Posted on
Apr 27 2017
Hi gauche,
Raygun distinguishes between crashes by putting an "UnhandledException" tag on the error report to say that it was detected through one of the automatic exception handlers - which generally means a crash. The report you've posted however does not have this tag, which most likely means the app did not crash as you are witnessing.
Is it that you were not expecting this report to be sent to Raygun at all? There are two main ways that this report may have been sent.
- You might be manually sending this exception to Raygun within a try catch block. You can search for usages of the RaygunClient.Send method in your app to see if this is the case. If this is why the report is being sent to Raygun, but you don't want the report to be sent to Raygun, then you could either remove the Send call, or filter this type of exception out.
- This exception might be caught inside the automatic UnobservedTaskException handler - which doesn't add the "UnhandledException" tag. If this is the case, there are two ways you could avoid the report being sent. One way to to not call the Attach or AttachCrashReporting methods on the client, and instead attach your own handlers to the AppDomain.CurrentDomain.UnhandledException and AndroidEnvironment.UnhandledExceptionRaiser events, and send the exception to Raygun within your handlers via the Send method on the client. Or, you could attach an event handler to the SendingMessage event of the Raygun client, determine if the exception passed in is something that you want to ignore, and if so, set the e.Cancel property to true.
Please let me know if neither of these seem to be the case, or if you have further questions about any of this.
-Jason Fauchelle
gauche
Posted on
Apr 27 2017
Hi Jason,
Thanks for the reply.
This still isn't adding up for me. I am not manually submitting any error reports, so we can rule out #1. And what's confusing about #2 is that the exception is observed. As you can see in my sample, there is a call to Handle to make sure the exception is marked as observed.
So why is the runtime still treating these as unobserved?
Thanks
Jason Fauchelle
Raygun
Posted on
Apr 27 2017
Hi gauche,
Within the Raygun UnobservedTaskException handler, the event args provides a boolean as to whether or not the exception was observed. Seems like the handler can be raised regardless of if the exception was observed. Within the handler, we could check if the exception was observed to determine if it should be sent to Raygun. We'll explore this further and get back to you.
-Jason Fauchelle
gauche
Posted on
May 03 2017
Any update on this Jason?
Jason Fauchelle
Raygun
Posted on
May 03 2017
Hi gauche,
I had a go at reproducing this issue yesturday, but can't get any unobserved task exceptions to occur at all using the example code you posted. I'm getting someone else to give it a go as well, which they should be doing today. In the mean time, please let me know which version of Xamarin you are using.
-Jason Fauchelle
gauche
Posted on
May 03 2017
Whaaa...?
OK, I'm using XF 2.3.4.224 for my app.
Full Xamarin tooling versions:
Microsoft Visual Studio Enterprise 2017 Version 15.1 (26403.7) Release VisualStudio.15.Release/15.1.0+26403.7 Microsoft .NET Framework Version 4.7.02046
Installed Version: Enterprise
Visual Basic 2017 00369-60000-00001-AA208 Microsoft Visual Basic 2017
Visual C# 2017 00369-60000-00001-AA208 Microsoft Visual C# 2017
Visual C++ 2017 00369-60000-00001-AA208 Microsoft Visual C++ 2017
Visual F# 4.1 00369-60000-00001-AA208 Microsoft Visual F# 4.1
Add New File 3.5 The fastest and easiest way to add new files to any project - including files that start with a dot
ASP.NET and Web Tools 2017 15.0.30320.0 ASP.NET and Web Tools 2017
ASP.NET Web Frameworks and Tools 2017 5.2.50303.0 For additional information, visit https://www.asp.net/
Azure App Service Tools v3.0.0 15.0.30209.0 Azure App Service Tools v3.0.0
Common Azure Tools 1.9 Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.
File Icons 2.6 Adds icons for files that are not recognized by Solution Explorer
HideMenu 1.0 Hides the Visual Studio main menu, similar to Windows Explorer and Internet Explorer
ILSpy.AddIn 1.0 Integration of the ILSpy Decompiler into Visual Studio.
JavaScript Language Service 2.0 JavaScript Language Service
JavaScript Project System 2.0 JavaScript Project System
JavaScript UWP Project System 2.0 JavaScript UWP Project System
KofePackagePackage Extension 1.0 KofePackagePackage Visual Studio Extension Detailed Info
Merq 1.1.17-rc (cba4571) Command Bus, Event Stream and Async Manager for Visual Studio extensions.
Microsoft MI-Based Debugger 1.0 Provides support for connecting Visual Studio to MI compatible debuggers
Microsoft Visual Studio VC Package 1.0 Microsoft Visual Studio VC Package
Mono Debugging for Visual Studio Mono.Debugging.VisualStudio Support for debugging Mono processes with Visual Studio.
NCrunch
Continuous Testing Tool for .NET
Copyright © 2010-2016 Remco Software Ltd
NuGet Package Manager 4.1.0 NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.
OpenOnGitHub 1.3 Visual Studio Extension for opening files on GitHub.com
Rebracer 1.0 Saves editor formatting settings as part of each solution.
Snippet Designer 1.6.5 Snippet Designer is a Visual Studio plug in which allows you to create and search for snippets inside the IDE
SQL Server Data Tools 15.1.61702.140 Microsoft SQL Server Data Tools
Trailing Whitespace Visualizer 2.5.83 Keeps your code files clean by making it easier than ever to identify and remove any trailing whitespace
TypeScript 2.1.5.0 TypeScript tools for Visual Studio
Visual Studio Tools for Universal Windows Apps 15.0.26403.07 The Visual Studio Tools for Universal Windows apps allow you to build a single universal app experience that can reach every device running Windows 10: phone, tablet, PC, and more. It includes the Microsoft Windows 10 Software Development Kit.
VSColorOutput 2.5 Color output for build and debug windows - http://mike-ward.net/vscoloroutput
Xamarin 4.4.0.34 (3f99c5a) Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.
Xamarin.Android SDK 7.2.0.7 (b16fb82) Xamarin.Android Reference Assemblies and MSBuild support.
Xamarin.iOS and Xamarin.Mac SDK 10.8.0.174 (7656cc6) Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
Jason Fauchelle
Raygun
Posted on
May 04 2017
Hi gauche,
I'm sorry to say that we still have not been able to reproduce the issue you've described. We have tried using the same version of Xamarin Forms, and running on an Android API 23 emulator. (We've tried other combinations too).
We're always seeing that with the device or emulator in flight mode, the result.Exception.Handle code will get hit, but the Raygun client never receives this exception in any way. However, by not observing the exception, the app still doesn't crash, and the Raygun client still doesn't receive any exceptions.
I'm not sure what we're doing differently to you. Could you please send us a simple project that reproduces the issue (without a Raygun api key). Then we'll be able to get to the bottom of this.
-Jason Fauchelle
gauche
Posted on
May 11 2017
I have a sneaking suspicion this is due to our use of AndroidClientHandler. I just noticed Xamarin 15.2 fixes this issue that sounds a lot like my problem. I haven't verified yet (or had time to create a repro for you), but just thought I'd post my feels here. Any chance you could try AndroidClientHandler in your repro and see if that triggers the problem?
Deleted User
Raygun
Posted on
May 12 2017
Hi Gauche,
I have been looking into this issue and I am sorry to say I cannot reproduce it even when using the AndroidClientHandler. Please let us know if updating to Xamarin 15.2 fixes the issue for you and if you have time we would love try out a simple test project if you can provide one.
Regards, Mitchell.
gauche
Posted on
May 16 2017
Hi Mitchell,
I'm still on 15.1 because 15.2 is a mess. However, I thought I'd test my theory. Here's what I did:
- Modify a page in my app so that all it does is kick off the request per my code above
- Turn on airplane mode on my phone
- Set breakpoints in various places
- Run it up
- Sure enough, Raygun
SendingMessagehandler is hit. Interestingly, it was hit before myContinueWithcall executed. - Change from
AndroidClientHandlertoHttpClientHandlerand run it up again - The code now worked as expected. The
ContinueWithcall was executed and theSendingMessagecallback was not
So it seems my hunch was correct, and that it's very likely 15.2 will fix this. As soon as I can actually upgrade to 15.2 I will check again and update this thread.
I guess the only point of confusion is why you can't repro. If I get time I will try to put together a standalone repro as well.
Deleted User
Raygun
Posted on
May 18 2017
Hi Gauche,
I've found that constructing the request message with an invalid url will result in an exception being thrown. It is caught by Raygun before the call to ContinueWith. From our tests using a valid url results in ContinueWith executing and Raygun not seeing any exceptions.
It is confusing why we can't reproduce the same problem. I'm glad there is a possible resolution to the problem coming with 15.2 though.
Cheers, Mitchell.
gauche
Posted on
Jun 27 2017
Seems like 15.2 has definitely fixed this.
ben.kloosterman
Posted on
Jul 28 2017
This happens in all languages and all systems its part of standard exception handling which is up to your program.
gauche
Posted on
Jul 28 2017
This happens in all languages and all systems its part of standard exception handling which is up to your program.
Wut? Did you actually read the thread?