I'm on Prism Unity 8.1.97 with VS2022 and net6.0-windows project.
In my App.xaml.cs I registered a dialog like this inside RegisterTypes():
containerRegistry.RegisterDialog<MyDialog, MyViewModel>();
When the application tries to show the dialog like this:
_dialogService.ShowDialog("MyDialog", parameters, r => { });
I can see the following Debug output in Visual Studio but the debugger doesn't break so I get no info on the exception:
Exception thrown: 'Prism.Ioc.ContainerResolutionException' in Prism.Unity.Wpf.dll
I tried this in App.xaml.cs to get more info on the exception but the event handler doesn't seem to execute. Dialogs aren't modules?
While debugging the application, I can do the following and it returns a not null object:
_iocContainer.Resolve<object>("MyDialog")
How can I get access to the ContainerResolutionException details?
Why isn't this working anyway?
Related
According to this and this, it should be easy to have Android Studio break on an uncaught exception. However, whatever I try, I seem not to get it working.
I set the "Class Filter" on my Activity, but the app just crashes on an uncaught exception, no breakpoint triggered.
Are you sure that the exception being raised is from the class that you've specified in the class filter?
Try configuring to break on all exceptions without the class filter enabled to validate that it's actually the specified class raising the exception: https://stackoverflow.com/a/28862538/3063884
I was unable to get the debugger to stop for anything until I clicked on the app folder in the project view (one level below root). Clicking on the Root folder of the project didn't work either.
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'm trying to create a crash report for my application. Getting the stack trace is easy when the game is running with debug: it is included in the Error object that is created in the crash. but when running with no debug, this information is missing.
Is there any way to get this information?
You can use try-catch blocks in suspicious places of your app.
try {
ExternalInterface.call('conf', 4);
ExternalInterface.addCallback('transcodeReqAnswer', analyseTranscodeAnswer);
} catch(er:Error) {
debugTextField.text = er.getStackTrace();
}
If you are compiling in debug mode you have to pass the parameters to javascript through ExternalInterface. Then you should be able to see the stacktrace from the console output of your browser.
Example:
flash.system.Security.allowDomain(sourceDomain)
ExternalInterface.call("print", error.getStackTrace());
and in JavaScript there should be a function
function takeLog(string) {
console.log("stacktrace: " + string);
}
In non-debug mode the getStackTrace() function returns null.
More information in the official documentation,
ExternalInterface.call(),
getStackTrace()
I have deployed my service and attached Visual Studio to the process to debug in one Visual Studio instance, and in another I have a client console test application that I run in debug mode, I can see both service methods that I call executed in the debugger, but in the second one where I throw an exception on purpose, I never see the code in ErrorHandlerBehavior called at all.
Is my registration for ErrorHandlerBehavior not correct?
I wonder if I need to have a behaviour extension in my service configuration for this?
I based my global exception handling off of the this example
Here is my container registration in my service program main method:
container.AddFacility<WcfFacility>(f => f.CloseTimeout = TimeSpan.Zero);
container
.Register(Component.For<WcfProtoType.IServiceProtoType>()
.ImplementedBy<WcfProtoType.ProtoTypeService>()
.Named("ProtoTypeService")
.AsWcfService( new DefaultServiceModel()
.AddEndpoints(WcfEndpoint
.BoundTo(new BasicHttpBinding(BasicHttpSecurityMode.None))
.At(baseUrl)
).PublishMetadata(o => o.EnableHttpGet())),Component.For<ServiceBase>().ImplementedBy<MyService>(),
Component.For<ErrorHandlerBehavior>().Attribute("scope").Eq(WcfExtensionScope.Services));
I looked at the Castle Windsor source and from what I can tell the EndPointBehavior needs to be registered first like this:
container
.Register(Component.For<ErrorHandlerBehavior>().Attribute("scope").Eq(WcfExtensionScope.Services),
Component.For<WcfProtoType.IServiceProtoType>()
.ImplementedBy<WcfProtoType.ProtoTypeService>()
.Named("ProtoTypeService")
.AsWcfService( new DefaultServiceModel()
.AddEndpoints(WcfEndpoint
.BoundTo(new BasicHttpBinding(BasicHttpSecurityMode.None))
.At(baseUrl)
).PublishMetadata(o => o.EnableHttpGet())),Component.For<ServiceBase>().ImplementedBy<MyService>());
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.