The documentation for BackgroundTaskCompletedEventArgs.CheckResult says:
Throws an exception if the background task completed event has reported an error.
I've tried making a background task that throws an exception in its Run method, but when I subscribe to its Completed event and call CheckResult when it completes, no exception is thrown.
When does CheckResult actually throw an exception?
It should work exactly as you have described: if an exception is thrown in IBackgroundTask's Run method, then BackgroundTaskCompletedArguments.CheckResult() method throws an exception when you call it.
Make sure that your background task actually runs and that your app is in foreground otherwise IBackgroundTaskRegistration.Completed event is not raised at all.
If you want to try it out on a working exaple, download Background task sample and make two modifications to it:
In Task\ServicingComplete.cs add throw new Exception(); at the very end of Run method.
In BackgroundTask\ServicingCompleteTask.xaml.cs add args.CheckResult(); at the beginning of OnCompleted method.
If you now run the app, register the task from the UI and trigger it from Visual Studio's Debug Location toolbar when the app is in foreground, you will notice that the CheckResult() call will throw an exception as expected.
Related
When I run a Flex/AIR application in debug mode and an error occurs, I see this:
TypeError: Error #1009: Cannot access a property or method of a null object reference.
However when the application has been installed as a release build and the same error happens, I don't see an error message.
Is it possible for my application to either save these types of errors to a log file or email them to me?
I have managed to implement this myself using the UncaughtErrorEvent and airxmail classes.
It was a simple case of adding the UncaughtError event to loaderInfo (within a method which is called by the FlexEvent.APPLICATION_COMPLETE event). Using these two classes, the application emails the runtime errors to me as and when they occur, in release mode only as the UncaughtError event does not fire in debug mode.
If you want to log your uncaught errors you can use the uncaughtError event.
loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR,handleGlobalErrors);
function handleGlobalErrors( evt : UncaughtErrorEvent ):void
{
//code that saves error to log or send by email..
evt.preventDefault();
}
You can find more information about this feature here http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/UncaughtErrorEvent.html.
Also beware that if you use this in Debug mode all your errors will be caught by the handleGlobalErrors function so keep that in mind.
I have a logger which is supposed to catch uncaught error, and send the tracestack to a server.
I'm trying to write unit tests to make sure this works. However, when I throw an error or errorEvent in my test classes, the FlexUnit Runner catches the error and doesn't let the test continue.
How can I unit test this?
The solution to my problem was to call event.preventDefault(); when the error was caught.
This prevents the normal behavior of the error to happen, allows my custom events and unit tests to run.
In a MFC application, where to put a topmost try/catch?
I have a MFC application and I would like to catch all the exceptions and show my own message box.
This is my idea for a topmost try/catch block:
try
{
// What enclose here? Or, where to put this try/catch block?
}
catch( const std::exception& e )
{
::MessageBox(0,e.what(),"I do not know hot to handle this exception, I will terminate",MB_OK);
}
catch(...)
{
::MessageBox(0,"Unknown Excpetion","I do not know hot to handle this exception, I will terminate",MB_OK);
}
::TerminateProcess( ::GetCurrentProcess(), -1 );
But, where can I put the block?
I created a MFC dialog based application with Visual Studio 2010, and compiled it in Release x64, I am on Windows 7.
I throw a std::exception (passing a string to the constructor) in an OnTimer method and without the block I get a message box created by csrss.exe with this generic message
"The exception unknown software exception (0x40000015) occurred in the
application at location 0x5dff61c9."
"Click on OK to terminate the program"
"Click on CANCEL to debug the program"
The message box does not report the string I attached to the exception and so it is not so useful.
I think I get the message box instead of a fancy TaskDialog because I disabled the Windows Error Reporting Service and renamed the WerFault.exe.
Maybe I have to forget my own message box and I need to embrace the new Windows Error Reporting?
The correct way to process unhandled exceptions in an MFC application is by overriding CWinApp::ProcessWndProcException
You may want to only handle certain exception types. If you want to fall back on the default behavior in some circumstances, call the base implementation. If you do not call the base, your app will not shut down.
If you want to display a custom error message and then shut down while avoiding the default message, display your message box and then call DestroyWindow on your main frame/dialog.
I have a windows service, in which I want a top level try-catch that catches any otherwise unhandled (or bubbled) exception, logs it to the Event Log and then swallows it so the service keeps running. However, I can't find any overload to System.Diagnostics.EventLog.WriteEntry that takes an exception as a parameter - is there no way to just give the event log the exception and let it parse out the message on its own?
Unfortunately there is no standard way of just passing the Exception to the Eventlog, built in to the .NET framework.
To have an exception written to the EventLog with the smallest development effort, you would need to write something like:
EventLog myLog = new EventLog();
myLog.Source = "Your Source";
myLog.WriteEntry(exception.ToString(), EventLogEntryType.Error);
But normally you would try to do some formatting of your exception.
Does throwing an exception in a windows service crash the service?
i.e. it will have to be restarted manually
Note:
I am throwing the exception from within the catch clause.
Not strictly so -- it'd only cause problems if the exception is unhandled.
If the exception is uncaught and bubbles back up to the OnStart() method it will crash the service. You will typically see a message in the Windows Event Log similar to the following:
"The MyServiceName Service service terminated unexpectedly. It has done this x time(s).
If you're throwing the exception in Catch, and there's nothing above it to recatch it, then that will cause your service to stop. The OnStart() method needs a try/catch. If you don't want to stop the service when an Exception occurs, then you need to handle it (log it and move on, or whatever).
My preference woudld be to handle expected exceptions, and to have unexpected exceptions either cause the service to stop, or at least stop/restart automatically. If something unexpected happens your service will be running in an unknown state, and who knows what it will do.
We ran into the problem of an untrapped exception on a child thread causing the service to stop without providing any information about what was causing the exception. We used this method to find out the source of the exception.
You can put a Handler to the service to catch all unhandled exceptions (including all sub threads of the service). In VB.NET, you will need to add a handler for AppDomain.CurrentDomain.UnhandledException. It is likely similar in C#. It will then catch anything that does bubble up past your onStart. You can choose to consume it there or allow it to crash the service from there.