Current dealing with an issue with exceptions being raised in hooks. When exceptions are thrown (at least from the "After" hooks), the previous scenario context is not disposed, which causes the log file for future scenarios to become unreadable.
As a temporary fix, I have added a try/catch around the test setup/teardown, however I want to be able to see that something has thrown without browsing the logs. We view the results from Jenkins, so if we could "fail" the test, we would be more likely to spot the issue.
Is there any way of doing this manually, without allowing the exception to be thrown?
In your catch block, do an intentional false assertion like something below..
Assert.True(false); //(Xunit)
Assert.IsTrue(false); //(Nunit)
This would make your test fail in the hooks without throwing the exception.
Related
I'm attempting to initialize an IDXGIFactory4 using the CreateFactory2 function however this throws out an error:
onecore\windows\directx\database\helperlibrary\lib\perappusersettingsqueryimpl.cpp(121)\dxgi.dll!00007FFBA0D6D7F8: (caller: 00007FFBA0D4D167) ReturnHr(1) tid(64d8) 8000FFFF Catastrophic failure
onecore\windows\directx\database\helperlibrary\lib\perappusersettingsqueryimpl.cpp(98)\dxgi.dll!00007FFBA0D6D4D0: (caller: 00007FFBA0D3E221) ReturnHr(2) tid(64d8) 8000FFFF Catastrophic failure
onecore\windows\directx\database\helperlibrary\lib\directxdatabasehelper.cpp(999)\dxgi.dll!00007FFBA0D6D4FC: (caller: 00007FFBA0D3E221) ReturnHr(3) tid(64d8) 8000FFFF Catastrophic failure
I have not found any similar error messages online.
I have attempted running the function on its own and initializing as a different IDXGIFactory (e.g. IDXGIFactory2) instead but both still lead to the same issue.
ComPtr<IDXGIFactory> dxgiFactory;
UINT factoryFlags = DXGI_CREATE_FACTORY_DEBUG;
ThrowIfFailed(CreateDXGIFactory2(factoryFlags, IID_PPV_ARGS(&dxgiFactory)));
This is not the error as you describe it.
There is no real failure, there is no catastrophy, there is no even exception and there is no error code returned to you from the API call. What you are seeing is a glitch in internal API implementation that emits debug output with these strange lines. Apparently it is a small problem in Microsoft's API implementation and the weird format of the message suggests it comes from use of wil in one the modules: they probably intended to remove this output from Release build of the software but somehow it worked out in a different way and unintended debug output passed through...
The message is likely to correspond to recoverable internal error condition which is then handled and your API call ends up being successful. Nothing to worry about, it's just up to Microsoft to make things cleaner.
These errors happen even with any Blank app straight from the templates (or sample apps from Microsoft Github repos) in Visual Studio 2019 (v16.9.1). It's only annoying, apps never crash nor hang. However, this never happend before.
I hope Microsoft better fix this soon (it's bad for nerves and mental health). You can do nothing about it.
The documentation implies it will raise an exception if any part of the configuration fails but it doesn't seem possible to actually catch an exception (Swift 4.) Certainly, one cannot wrap the statement in a do..catch block. If it fails, is my app doomed to just crash or continue and try (and fail) to operate without Firebase?
FirebaseApp.configure() will only crash if there's something wrong with the configuration file that you download from Firebase's console.
If it worked for you one time, there won't be a reason for it to crash later unless you change the configuration file. So no need to try to catch the error or any special effort.
I have an application that handles the the CM_DIALOGKEY message on it's main form.
procedure CMDialogKey(var Message: TCMDialogKey); message CM_DIALOGKEY;
This worked up until some point recently, but I can't figure out at what point something was changed, and more importantly what. If I create a blank application, put in the message handler above then the message is handled and I can do things on certain keystrokes. Somewhere along the line some code must have been added that handles a message and doesn't propogate that message, but for the life of me I can't figure out what. Any ideas on how to go about debugging this? Breakpoints are obviously out of the question, unless someone has an idea of a breakpoint somewhere specific.
Any ideas on how to go about debugging this?
Here's how I would go about debugging this:
Use your version control system to isolate the commit that changed behaviour.
Using the last commit that worked as intended, set a breakpoint in CMDialogKey.
Run the program until the breakpoint triggers and make a copy of the call stack in this state.
Switch to the first commit that does not work. Now set a breakpoint higher up the call stack from step 3 which does trigger. You may need to work a little to find such a place, and you may need to use a conditional breakpoint. For instance you might need the condition Message.Msg=CM_DIALOGKEY.
Now step forwards and find the point at which the execution diverges from the call stack seen in step 3.
At this point you should have isolated the behaviour change and be in a position to investigate a solution.
I am developing an application and I have to submit an error report, I have to save all errors I face in database or word file, etc. Exceptions have to be saved in order to know what kind of exceptions we are facing and to fix them later on.
I have to write code in one place to catch any error that happens. Can anybody help me in this? Where do I write this code and even what is the code to be written in order to achieve my aim?
Here are a couple of links that discuss catching exceptions:
Xcode all exceptions breakpoint.
Installing exception handler
Hope that helps!
All,
I have a chunk of code that runs over a lot of records and in about half of the cases fails (this is ok, some records simply don't have the required data) I put this code in a #try #catch block to make it run smoothly, we try to do our thing, if we fail, we have some default action.
When it fails in the #try block often it is a unrecognized selector error, since it is in the #try block I catch this error, but it still gets logged everytime, even when I don't log from my #catch block. This is very annoying because it clogs up my logging. If I want errors from a #try/#catch logged, I will take care of that in the #catch right?
How can I stop XCode from logging errors in the #try block that are subsequently resolved in the #catch block?
I am using XCode 4.2
Thanks
In Objective-C using exceptions for any normal situation that can appear in a program is a no go. Exceptions are used only for discovering and catching programming errors and terminating gracefully. The problem is that all of the standard libraries (Cocoa, CoreFoundation, C standard library, ...) just are not build to handle exceptions and would fail to clean up resources if exceptions went through them.
Theoretically you could use exceptions if you made sure that you do your memory and other cleanup correctly and do not throw through foreign code. If you use ARC, there's a compiler switch -fobjc-arc-exceptions that would help you to get memory management (in your code) right.
Common practice is not to use exceptions at all (other than bugs, for example using NSAssert).
Exceptions themselves do not log any message to the console. Neither does Xcode (by default) log any exception throwing.
It's the error catching code that writes the messages before throwing exceptions. NSObject's doesNotRecognizeSelector: prints a message when unrecognized selectors are being sent. You cannot turn this off.
So you want to see certain log message but not others. How about redirecting the debugger output into a file. On that file use grep or a text editor with nice filtering to scan through message you want to see. Copy & paste from the gdb console into an edtor would do the same trick.