When an exception occurs in debug mode. I would quite often go back to the previous line with the yellow debugger arrow, edit the code, then keep running step by step.
It seems that now when some kind of exceptions are thrown, it's not possible to move the debugger cursor until the exception has been caught. Is there a workaround to make this work again?
That makes the progress of quick testing much more difficult.
EDIT:
This appeared after updating to vs 16.8 (then 16.8.1)
Issue occurs with .NET 5 or .NET 3.1, or .NET framework 4.7.2, not a framework issue
I uninstalled Resharper to rule this out
if I just do throw new exception("Pause"); or do a divide by zero it will not cause the issue.
if it is involving Sytstem.Linq then I will have the issue.
Example:
using System;
using System.Linq;
namespace TestDebug
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
int[] test = null;
var error = test.Any();
Console.WriteLine("Bye bye World!");
}
}
}
EDIT2:
The tooltip is different in my example from what I would see with a different exception such as a divide by zero exception. (see comment).
The tooltip when I can't drag the cursor is saying:
"This is the next statement to execute when this thread returns from the current function"
It does not suggest to drag the cursor as it would normally do
Related
I am working on a DirectX 11 app and I am having difficulties creating an instance of IDXGIFactory7. I could not find a CreateDXGIFactory7() function so I am using CreateDXGIFactory2() like this:
IDXGIFactory7* factory;
HRESULT hr = ::CreateDXGIFactory2(DXGI_CREATE_FACTORY_DEBUG, __uuidof(IDXGIFactory7), (void**)&factory);
The difficulty I am having is that this call throws an exception when attempting to use the graphics debugger in Visual Studio 2019. I also tried IDXGIFactory6 which also throws an exception. If I change it to IDXGIFactory2 it works and I can use the graphics debugger.
This code does run and debug fine using the regular debugger, but not the graphics debugger. I get the following exception:
Exception thrown at 0x00007FFAE1513B29 in DirectXTemplated.exe: Microsoft C++ exception: GRFXTool::ToolException at memory location 0x0000004D28BFE010.
I downloaded the sample from https://www.3dgep.com/introduction-to-directx-11/ and modified it to use IDXGIFactory7 and CreateDXGIFactory2() instead of IDXGIFactory in the QueryRefreshRate() function. You will need to set g_EnableVSync = TRUE at the top of main.cpp for it to create the factory. This does generate the exception when attempting to use the graphics debugger.
This is a Windows 10 Pro x64 installation with Visual Studio v16.7.6.
Based on the comment from Roman R., the way to get around the problem seems to be to use CreateDXGIFactory2() to create an IDXGIFactory2 and use QueryInterface() on that to obtain the one for IDXGIFactory7.
Doing it this way avoids the exception and the app runs under the graphics debugger without issue.
The problem
I'm trying to scroll on an Ionic App. I would like to scroll until an element is visible.
To test the procedure, I've written two sequential actions.
While testing just the first one is evaluated, the second one throws an exception Support for this gesture is not yet implemented.
How do I scroll, like a user would do, untill an element is visible if I cannot repeat actions?
Environment
Appium version 1.6.4-beta
Desktop OS/version used to run Appium: OSX Sierra
Real device or emulator/simulator: iPad Mini
Code To Reproduce Issue
TouchAction action = new TouchAction(this.driver);
Thread.sleep(5000);
action.press(150, 150).moveTo(0, 350).release().perform();
Thread.sleep(10000);
action.press(150, 150).moveTo(0, 350).release().perform();
The only possible, and horrible, solution that I've found is:
while( !element.isDisplayed() ){
TouchAction action = new TouchAction(this.driver);
action.press(150, 150).moveTo(0, 350).release().perform();
Thread.sleep(5000);
}
Hopefully someone can suggest a cleaner solution.
Have a system build using C++ Builder 2010 that after running for about 20 hours it starts firing of assertion failures.
Assertion failed: xdrPtr && xdrPtr == *xdrLPP, file xx.cpp, line 2349
Tried google on it like crazy but not much info. Some people seem to refer a bunch of different assertions in xx.cpp to shortcomings in the exception handling in C++ Builder. But I haven't found anything referencing this particular line in the file.
We have integrated madExcept and it seems like somewhere along the way this catches an out of memory exception, but not sure if it's connected. No matter what an assertion triggering doesn't seem correct.
Edit:
I found an instance of a if-statement that as part of it's statement used a function that could throw an exception. I wonder if this could be the culprit somehow messing up the flow of the exception handling or something?
Consider
if(foo() == 0) {
...
}
wrapped in a try catch block.
If an exception is thrown from within foo() so that no int is returned here how will the if statement react? I'm thinking it still might try to finish executing that line and this performing the if check on the return of the function which will barf since no int was returned. Is this well defined or is this undefined behaviour?
Wouldn't
int fooStatus = foo();
if(fooStatus == 0) {
...
}
be better (or should I say safer)?
Edit 2:
I just managed to get the assertion on my dev machine (the application just standing idle) without any exception about memory popping up and the app only consuming around 100 mb. So they were probably not connected.
Will try to see if I can catch it again and see around where it barfs.
Edit 3:
Managed to catch it. First comes an assertion failure notice like explained. Then the debugger shows me this exception notification.
If I break it takes me here in the code
It actually highlights the first code line after
pConnection->Open();
But it seems I can change this to anything and that line is still highlighted. So my guess is that the error is in the code above it somehow. I have seen more reports about people getting this type of assertion failure when working with databases in RAD Studio... hmmmm.
Update:
I found a thread that recursively called it's own Execute function if it wasn't able to reach the DB server. I think this is at least part of the issue. This will just keep on trying and as more and more worker threads spawn and also keep trying it can only end in disaster.
If madExcept is hinting that you have an out of memory condition, the assert could fail if the pointers are NULL (i.e. the allocation failed). What are the values of xdrPtr and xdrLPP when the assert occurs? Can you trace back to where they are allocated?
I would start looking for memory leaks.
In my MonoDroid application, when an unhandled exception occurs the application terminates without any messages. If I can reproduce the error on my local device I can debug it through Visual Studio without any problems.
However, on remote devices I am stuck for a solution.
I have tried the following in the Application class but it does not actually write my log file, unless I am running through the debugger in Visual Studio.
public override void OnCreate()
{
base.OnCreate();
AndroidEnvironment.UnhandledExceptionRaiser += new EventHandler<RaiseThrowableEventArgs>(AndroidEnvironment_UnhandledExceptionRaiser);
}
void AndroidEnvironment_UnhandledExceptionRaiser(object sender, RaiseThrowableEventArgs e)
{
// Write Log File
}
I disagree with #SpiritMachine's answer.
Mono documentation tells us:
Note: You cannot rely on the AppDomain.UnhandledException event as managed exceptions are never unhandled in MonoDroid; they are always intercepted at the Android/managed boundary within a catch(Exception) block.
Instead, I recommend that you do the following:
AndroidEnvironment.UnhandledExceptionRaiser += (sender, args) =>
{
// Do something...
};
Try something like this:
EDIT : This code cannot handle caught errors. Please see #Jim G.'s answer....
Personally, I would localise error handling to where you need it. The reason being, you don't know what your application state will be when this handler is recruited - you may be without resources that you're depending on to do the handling...
(edit: this question is about BB specifically, because of the strange way it optimises exceptions. I am comfortable with normal exception handling patterns in J2SE, but BB does not behave as per normal. Specifically in this case, BB discards the error type, and message, and how BB devs try to deal with this issue, or if they ignore it.)
I would like to implement some form of custom global error handling in my BB app. Specifically to try to handle any other exceptions that were not caught by my code, because I had not expected them. The default behaviour is that the app fails, and a dialog pops up saying an Unknown error occured.
I would like to describe the error a little bit better, hence my term "global error handler". Something similar to the code:
public static void main(String[] args)
{
try
{
FusionApp app = FusionApp.getInstance();
app.enterEventDispatcher();
}
catch (Throwable t)
{
// t has lost all type information at this point - this prints "null"
System.err.println(t.getMessage());
}
}
My immediate problem is that when I catch t (in the main() method after the app.enterEventDispatcher() call), it has lost its type information. e.g. I know that the code throws an IllegalArgumentException with a custom message - however in the catch block, it is a java.lang.Error with null message.
And in the stack trace (ALT LGLG), the message has also been lost (at least the stack trace is accurate).
So... what is a good pattern to use to implement some form of global error handling on BB? Or is this considered a bad idea on this platform?
Is it considered good practice to just have the unknown error dialog box pop up - I don't like this, but maybe that is the way of the BB?
Best practices are to implement custom exception handling.
So, if you expecting to catch IllegalArgumentException, MyCustomException and StartupException, put them into catch block first, and then put an Exception catch (and then, if you like, put a Throwable catch)
The common rule is - from most exclusive to most common, and for exceptions of the same level - from most expected to least expected.
In case of exception == null or getMessage() == null you can always display something like "Application error, please send event log to [support email]" message, then if you have a nice event logging in you app, you have a good chance to reproduce an issue.
And talking about event log, see EventLogger class to implement logging.