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.
Related
It seems catching System.ServiceModel.EndpointNotFoundException doesn't work in orchestrations despite of:
port settings: Delivery Notification = Transmitted (it should work without this in two-way port)
catching exception in specific order
catching Microsoft.XLANGs.BaseTypes.DeliveryFailureException
catching super class exception CommunicationObjectFaultedException like here
scope in scope configuration like here
Orchestration only catches System.Exception. Is that bug or am I missing something?
EDIT :
My configuration:
Sendport WCF-WebHttp
Endpoint REST
I managed to put Microsoft.XLANGs.Core.XlangSoapException catch type by editing odx file in notepad (its hack!)- and This actually works as I want becasue
this type encapsulates System.ServiceModel.EndpointNotFoundException by Biztalk I persume.
This type of exception is thrown in orchesration but VS doesnt let me choose this type of exception I believe that is done in purpose to not to do that.
In the EFContextProvider (EF6) SaveChangesCore method, the exception handling looks like this:
} catch (Exception e) {
while (e.InnerException != null) {
e = e.InnerException;
}
throw e;
}
This throws only the most internal exception and hides the relevant information revealed by the external exceptions.
When the SaveChanges process goes through multiple layers the next direct layer exception is lost, and only the last exception in the chain is thrown. It doesn't allow to handle well the exceptions for the caller.
Updated Post
As of Breeze 1.4.6, any .NET Exceptions thrown on the server are now available in their original form in the httpResponse.data property of any async breeze result. Breeze will still drill down to extract a "good" error message, but will no longer obscure the initial exception.
Original Post Below -------------------
It's an interesting point. The reason we did this was because most client side apps aren't written to navigate thru the exception chain and we wanted to expose the most 'relevant' error to the client. Most of the apps we looked at just exposed the client "error.message" property directly and with EF errors this was almost always useless.
However, your point is well taken. I think what we need to do is create a new Exception that has a top level message that is the innermost exception message but still expose the entire exception chain for those that want to drill. I've added an internal feature request for this and will try to get it into a near term release ( probably not the next one because we are already in testing for that one).
And thanks for the input.
I'm working on some flash app. Now, to test customer side of it I can use Flash Player debugger version that will save logs and show error messages. When it's deployed on the customer side - they will have a regular Flash Player version which means I will have no access to error messages if errors will happen. So I would like to equip it with some tool that would capture all of my trace messages in code and errors text. As for trace messages that's fairly simple, I just override the function in my code so it sends a POST request with trace message to a logger server, but how can I get a hold of the error message? Is there a known approach to this or some trick that somebody can suggest?
You can install the debug version of flash as your browser's default (in Chrome, you must disable the built-in player), so if you wanted to test user experience and debug, this would be the ideal solution.
However, to answer your question: there's no method for universally catching all errors, and redirecting them (that I know of). You'd have to encapsulate problem code ahead of time with try...catch statements, and send the property back on catch. For example:
try {
this["foo"]();
} catch (e:Error) {
trace(e);
}
In the debug version, the traced value would be TypeError: Error #1006: value is not a function. And while the standard version will only output TypeError: Error #1006, (a notably less descriptive error), what we're missing is any reference to where the error occured. To get this, we need to use Error.getStackTrace() to see the call stack and the line where the error occurred. In debug, this outputs the following:
TypeError: Error #1006: value is not a function.
at Shell_fla::MainTimeline/init()[C:\Projects\shell.as:91
In the standard client, we get a dissapointing null. In short, you cannot get any valuable info from the client versions.
The best advice I can give is to write around your problem code with your own custom error reports. For example, catch IO errors and trace the file it failed to load, or if you're expecting an object.foo, first try if (object.hasOwnProperty("foo")) { // do something } else { trace("foo not found in " + object.name) }. Code defensively.
Cheers,
I've discovered this post on StackOverflow:
How to catch all exceptions in Flex?
It answers my question, strange that I haven't ran into it while I was googling prior to asking.
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.