The only solution I seem to be able to find for testing for exceptions is using SenTestingKit's STAssertThrows and STAssertThrowsSpecific, however in both cases when the exception is thrown the application under test hangs until I manually ask it to continue. Surely the exceptions should be swallowed by the testing framework? And if not, does anyone have a beter suggestion for testing exceptions?
I was going to delete this question, but here is the solution for anyone else who finds themselves in a the same situation:
The reason that the application was breaking was that I had an Exception Breakpoint set up. This breaks as soon as an exception is raised, not when it bubbles up, so it was actually being halted before it had even got as far as my assertion. I just need to toggle off breakpoints (or just the exception breakpoint) when I am running tests.
Related
I'm not sure if I'm missing something here, but it doesn't appear to be possible to debug exceptions in Jetbrains Rider.
I have an incredibly simple piece of code that throws an exception (invalid file name) and there is no way I can find to
a) stop on the exception line in my code raising the exception, and
b) view the value of any variables in my source code that may have contributed to the exception.
I've recorded a sample video here that shows the debug attempt, and why it seems illogically impossible.
Has anyone found a way of debugging this stuff? Is Rider actually broken?
Sample video showing (attempted) debug session
For anyone experiencing the same situation, enable "Any Exception" and disable "Only break on exceptions thrown from user code" in Breakpoint Options.
You can also (as #mu88 mentions) disable debugging of external sources, but that simply reduces the clutter in stack frames.
My program runs for about 10 hours during the night, sometimes I wake up to see that it has crashed (for whatever reason). It is usually a "Program Name" has stopped working, and the only button there is to close the program. I have tried watching and waiting for it to crash but the problem seems very hard to reproduce (and I can't watch it 24/7). I have used try and catch statements in my program in potentially problematic areas and told the program to dump to a text file if it catches an exception. But this isn't good enough it seems.
TLDR: Is it possible to tell my program to run a particular function when an exception has been detected in the program in general (without specifics) so that I can dump the stacktrace to a text file and investigate later?
Is it possible to tell my program to run a particular function when an exception has been detected...
Yes, but the specifics depend on the platform that you are using:
If you have a Console application, put a big Try ... Catch around Sub Main.
If you use WPF, add an event handler to AppDomain's or Dispatcher's UnhandledException event. Specifics can be found in the following question:
WPF global exception handler
In you use WinForms, you can also wrap Sub Main (which might be auto-generated) or attach to AppDomain.UnhandledException, see here for details:
WinForms Global Exception Handling?
For completeness, global exception handling in web applications is done in global.asax's Application_Error method:
How to catch unhandled exceptions in an asp.net application?
It's generally not a good idea to do this. You could, however, look at AppDomain.UnhandledException. This is pretty much restricted to one domain, and you'll also receive (potentially) notifications for all unhandled exceptions unrelated to your program.
This is usually used for class libraries, but I think with a bit of fiddle, you might get it to work.
I'm working on a VB.Net program in debug in Visual Studio 2010 (10.0.40219.1) (Windows XP 5.1 2600.xpsp-sp3-gdr.120821-1629), and have noticed that while debugging it runs very slowly. When run as an executable (even the debug executable) it bowls along at a splendid speed.
The cause appears to be that the development environment is generating large numbers of exceptions (appearing in the immediate window).
A first chance exception of type 'System.ArgumentNullException
occurred in Microsoft.VisualBasic.dll
Does anyone know what the cause of this might be? It doesn't appear to have any adverse effect on the running of the program, other than to take a long time to get to the bit I'm trying to find the bug in. The exception doesn't appear to be related to any particular patch of code, and indeed it doesn't happen for most other projects.
I found an answer to a similar question for you:
A first chance exception
I would pay specific attention to the suggestion by Marcus Andren:
If you want to pinpoint where the exceptions are occurring, you can
select the Debug->Exceptions menu item, and in the dialog that
appears, check the first checkbox for "Common Language Runtime
Exceptions". This will make the debugger break as soon as an exception
occurs instead of only breaking on unhandled exceptions.
This is also one reason why it is generally a bad idea to catch
generic exceptions unless you are clearly logging the information
caught.
I am running some UI tests using WebDriver and MSpec. I added a check in Cleanup that no JavaScript errors were raised. But, throwing an exception in here doesn't fail the tests. How can I get this to work? I need to fail any test, and don't really want to do this separately in each test.
If I remember correctly, there isn't really a way to do this in a cleanup. Cleanups happen after tests, so it would be too late to fail them. As a matter of principle, it may be better to write the assertion for it not raising any javascript errors as its own spec at the end of each of them.
Even if it can be done from the Cleanup code, it should not be done that way.
Reason: How would you know which of the multiple tests that you have failed?
I don't like the fact that VB.NET is silently failing on an operation if something goes wrong:
Dim n(10) As String
n(11) = "blah"
I do not want to handle such situation with a Try/Catch/Finally, that would be an overkill.
I will stumble over such situations while testing my application during development.
But the fact that VB.NET simply skips over this error is a bit annoying.
Can I change the IDE so that it breaks in this line?
Thank you very much!
Click Debug, Exceptions, then check all of the checkboxes.
The debugger will not break whenever any exception is thrown anywhere, even if it is subsequently handled.