Visual Studio 2019 .NET Core C# Windows Forms development.
SqlDependency.Start is causing a SqlException. But it happens after .Start completes with return code True. So catch does not catch it. Happens periodically. Can see it in VS Output:
Exception thrown: 'System.Data.SqlClient.SqlException' in System.Data.SqlClient.dll
Checking SSMS log file:
Service Broker needs to access the master key in the DB. Error 32.
But I see this once. Whereas VS Output shows SqlException in groups of 5 separated by tens of seconds.
In general how can one setup a way to monitor all SqlException that happen outside of a response to a call. Say a time out exception perhaps not that I know if it happens.
In particular suggestions for resolving this are appreciated. I tried setting TRUSTWORTHY to YES but it did not help.
Not sure if SqlException and the log message are related.
Thanks!
That an exception is thrown is not necessarily an issue. It's quite normal for exceptions to be thrown. The VS debugger will show you every exception that is thrown but the vast majority of those are being thrown, caught and dealt with in system code and are most likely of no concern to you.
That said, you can configure VS to break whenever a particular type of exception is thrown, rather than the default of when it goes uncaught. While debugging, open the Exception Settings window, find the exception of interest and check the corresponding box to break whenever that exception gets thrown. It seems that you want the System.Data.SqlClient.SqlException under the Common Language Runtime Exceptions node.
Related
I have a problem when using the method AssertConfigurationIsValid(). The expected result should display a exception containing the details of mapping, instead it throws this error:
I expect to see a well detailed error at this point but instead throw this.
Did I missed something when install AutoMapper extension?
This isn't a matter of getting the wrong result, you're looking the wrong place.
You're showing us a notification that an unhandled exception occurred. It only mentions that "an exception of type X" occurred, it doesn't show you the content of that exception, which is where you want to be looking.
Either change your IDE debug settings to not raise this notification (I generally don't like it), or handle your exception (i.e. catch it) and inspect it at debug time.
Note also that AssertConfigurationIsValid should generally be used in a test suite, where all exceptions (inside tests) are automatically handled and reported as a test result.
I'm new to Reactive Extensions. While running my application in Visual Studio, I get the following exception which I cannot reproduce reliably it but always happens given enough time:
System.TimeoutException was unhandled
Message: An unhandled exception of type 'System.TimeoutException' occurred in System.Reactive.PlatformServices.dll
Additional information: The operation has timed out.
The Break Mode tab shows the message:
Your app has entered a break state, but there is no code to show
because all threads were executing external code (typically system or
framework code).
I have no clue as to where to look for the problem, except that it might have to do with Reactive Extensions. Any ideas would be greatly appreciated.
The second message (Break Mode) is something that always gets shown in Visual Studio - that's the definition of "Break Mode" - In any application that you debug with VS you can "break" the app (using the "Pause" button, for example) - This allows you to better debug and understand the state of your parameters, objects and callstacks. The code is not showing up since you're using external code that your have no sources for.
Regarding the first exception, as you said, the platform services have a timeout. After a determined period of time something has not happened, the application will throw this timeout saying that the expected operation didn't complete in the amount of time that was specified for it. I can't tell you really why this is happening on your specific machine, but you should check if the extension requires something to initialize that you might not be providing it.
So, in my code, I am throwing an exception manually, using throw new XYZApplicationException(exceptionID) if table is not found in the database. That same exception is handled manually in a custom class named XYZApplicationException which inherits from System.Exception.
In the exception handler, I redirect the user to a different page (errordetails.aspx), where I display error details, and what to do in that scenario. This all works fine, but with a catch.
Every time exception is thrown, VS2010 displays error message saying "Exception was unhandled by user code". Then if I click continue, it redirects to errordetails.aspx fine. So, everything works perfectly, apart from that stupid message where I have to click continue.
I have no idea what might have caused the issue. So, any suggestion is welcome.
P.S. This error started occuring after upgrading to .Net 4.0 from .Net 1.1.
Edit:
Apparently, if I disable "Just My Code" in Debugging options in VS, it works fine. So, clearly application is thinking I haven't handled the exception, even though I did. Should I add some kind of declaration, that exception is handled, if my code handles it?
I'm getting exceptions thrown from somewhere, but all I get from the compiler is "A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll". This is fairly useless to me, as that's not my code (pretty sure it's default library). I'd like to see a stack-trace or something so I know where in my code things went wrong. It's a fairly large codebase (much of which is not mine), and there's a lot of multi-threading and other stuff going on, so it's nearly impossible to try and step through the code without some idea of where to start looking. Is there some setting somewhere to make ALL exceptions trigger a break so I can see the call-stack when they occur, rather than just having them silently fail with a completely useless error message in the output?
You have a couple of options. First, like Greg said, you can cause VS to break when any exception occurs:
Make sure these are checked, then click OK:
That will cause Visual Studio to break wherever the exception occurs.
Another approach is to catch the exception and either write just the stack trace, or write the exception (using ToString()) to the output window:
Then check your output window:
I have a Windows Forms application. It loads assemblies with the extension .Plugin.dll with Assembly.LoadFile. One of these "plugins" calls into another assembly dll. That dll eventually throws a ValidationException exception. The method that throws the exception is in a class that inherits from IDataErrorInfo. This class is a class that is contained in a Linq to SQL class (.dbml). In the "plugin" I call DataContext.SubmitChanges. This is wrapped in a try/catch block. This causes my business logic to validate the data before submitting to the database in the OnValidate override. The result that I see is that after the ValidationExeption is thrown, the debugger stops at the bottom of the OnValidate method indicating that an unhandled exception has occured. If I continue to run the app my catch block is executed. That is what I wanted in the first place, but why am i getting an unhandled exception when it truly is handled?
I am 99% sure your "real" exception causing this is indeed unhandled -this is what the Debugger tells you at first place, and he is generally right.
When you continue to run the App in VS after that, it is not actually what would happen when you will execute your exe out of the debugger. In fact, the debugger notifies you first of the unhandled exception, and then continues some pending logic if any (that's why you see you ValidationException error). But the unhandled exception is still there. I don't exactly know the details and causes of this behavior, but I noticed this many times.
You have to catch the precise error at the precise place where the unhandledexception is thrown after you identify it.
Maybe posting your code sample would help.
Firstly, is the plugin in the same AppDomain?
Secondly, it sounds to be like you have your debugger to "Break when exception is thrown" rather than "Break when exception is user-unhandled".
In VS.NET, go to Debug --> Exceptions...
Expand the "Common Language Runtime Exceptions" node and see if any are ticked.