I'm using Sqlite in my ASP.NET Core 9.0 app. Whenever I debug in Visual Studio, I get hundreds of these errors in the output panel:

15:43:08:084    Exception thrown: 'Microsoft.Data.Sqlite.SqliteException' in Microsoft.Data.Sqlite.dll
15:43:08:084    Exception thrown: 'Microsoft.Data.Sqlite.SqliteException' in Microsoft.Data.Sqlite.dll
15:43:08:084    Exception thrown: 'Microsoft.Data.Sqlite.SqliteException' in Microsoft.Data.Sqlite.dll
15:43:08:340    Exception thrown: 'Microsoft.Data.Sqlite.SqliteException' in Microsoft.Data.Sqlite.dll
etc...

And it's not just that -- I get all sorts of Exception thrown: messages, in all sorts of libraries -- I can never catch them, and they don't seem to cause any damage.

15:49:05:175    Exception thrown: 'System.IO.FileNotFoundException' in Lucene.Net.dll

or

15:49:05:424    Exception thrown: 'System.FormatException' in System.Private.CoreLib.dll

Several times, I've debugged deep into my code, and I can isolate the method call that causes the error to appear -- it's always me calling someone else's code, so the exception is being thrown deep into code that I don't have any control over.

What are these? Should I be concerned about them?

I'm using Sqlite in my ASP.NET Core 9.0 app. Whenever I debug in Visual Studio, I get hundreds of these errors in the output panel:

15:43:08:084    Exception thrown: 'Microsoft.Data.Sqlite.SqliteException' in Microsoft.Data.Sqlite.dll
15:43:08:084    Exception thrown: 'Microsoft.Data.Sqlite.SqliteException' in Microsoft.Data.Sqlite.dll
15:43:08:084    Exception thrown: 'Microsoft.Data.Sqlite.SqliteException' in Microsoft.Data.Sqlite.dll
15:43:08:340    Exception thrown: 'Microsoft.Data.Sqlite.SqliteException' in Microsoft.Data.Sqlite.dll
etc...

And it's not just that -- I get all sorts of Exception thrown: messages, in all sorts of libraries -- I can never catch them, and they don't seem to cause any damage.

15:49:05:175    Exception thrown: 'System.IO.FileNotFoundException' in Lucene.Net.dll

or

15:49:05:424    Exception thrown: 'System.FormatException' in System.Private.CoreLib.dll

Several times, I've debugged deep into my code, and I can isolate the method call that causes the error to appear -- it's always me calling someone else's code, so the exception is being thrown deep into code that I don't have any control over.

What are these? Should I be concerned about them?

• c#
• runtime-error
• .net-9.0
• asp.net-core-9.0

• 1 Log the exception's Message property, if you can. That will have more info. Though I understand the reason you're here is you have a hard time finding these in the first place. – Joel Coehoorn Commented Feb 7 at 22:00

1 Answer 1

Stating obvious - those are exceptions :)... and yes you generally should be concerned about them if your application is expected to handle high load. Exceptions in .NET are relatively expensive and removing them may give you service performance boost. Measure first before diving into investigations.

Roughly there are three categories

• exceptions that can't be avoided (i.e. network failures, file access, and similar that can't be practically eliminated by checking state first). Those likely to stay there forever, you may want to confirm that those happen mostly at startup rather than each request. Some may be avoided with more specific configurations or dependencies (i.e. dynamic discovery of serializers throws some).
• using libraries that don't provide exception-less common failure handling. It's much easier (and generally recommended approach in .NET) to throw exception and handle them than carefully track errors in another ways. Works for most non-extreme-load cases. If you really find performance to be an issue - try to find alternatives/use lower-level libraries and write more code yourself. In some cases your own code may switch to "exception-less" variant of library API (similar to int.Parse to int.TryParse) but weight higher mental cost of handling error cases manually by developers vs. cost of exceptions.
• actual issues with your own code masked by ignoring errors deep inside libraries. Check if your code can directly impact the code that throws exception - i.e. passing "better" (like an empty string instead of null for string parameter) values may work. Some may be coming due to unexpected issues with data - SQLite/search once in the question may indicate ignorable problems - maybe missing index for DB or failing lookup for extra parsers for search (this are examples I can think of based on exceptions, but have not seen myself)

In either case you can investigate those exception by checking stack (and sometimes code if available) when exception is thrown. Sometimes you can see more information about exception that way. If you see your own code on the call stack it may indicate what could be done differently to avoid exception. Note that this is quite time-consuming and frustrating, so if you want to do such investigation focus first on exceptions during requests (as those represent recurrent cost).

To stop on exception outside of your code in Visual Studio you may need to disable "my code only" checkbox in debugger properties so it will stop when exception thrown from the library - exceptions with the debugger in Visual Studio.