{"id":3264,"date":"2022-10-11T21:34:54","date_gmt":"2022-10-11T21:34:54","guid":{"rendered":"http:\/\/putridparrot.com\/blog\/?p=3264"},"modified":"2022-10-11T21:34:54","modified_gmt":"2022-10-11T21:34:54","slug":"first-chance-exceptions-can-be-more-important-than-you-might-think","status":"publish","type":"post","link":"https:\/\/putridparrot.com\/blog\/first-chance-exceptions-can-be-more-important-than-you-might-think\/","title":{"rendered":"First Chance Exceptions can be more important than you might think"},"content":{"rendered":"

Note: This post was written a while back but sat in draft. I’ve published this now, but I’m not sure it’s relevant to the latest versions etc. so please bear this in mind.<\/em><\/p>\n

You’ll often see First Chance exceptions in the output window of Visual Studio without them actually causing any problems with your application, so what are they ?<\/p>\n

A first chance exception is usually associated with debugging an application using Visual Studio, but they can occur at runtime in release builds as well.<\/p>\n

A first chance exception occurs whenever an exception occurs. The exception is thrown at which point .NET searches for a handler (a catch) up the call stack. If a catch is found then .NET passes control to the catch handler code. So in this instance, let’s say we see a first chance exception which is caught in some library code. Then, whilst debugging, we’ll see the message that a first chance exception occurred, but it won’t cause an exception to halt an application because it’s caught. On the other hand if no catch is found the exception becomes a second chance exception within the debugging environment and this causes the debugger to break (if it’s configured to break on exceptions).<\/p>\n

We can watch for first chance exceptions by adding an event handler to the AppDomain.CurrentDomain.FirstChanceException<\/em>, for example<\/p>\n

\r\nAppDomain.CurrentDomain.FirstChanceException += CurrentDomain_FirstChanceException;\r\n\r\nprivate void CurrentDomain_FirstChanceException(\r\n    object sender, FirstChanceExceptionEventArgs e)\r\n{\r\n   \/\/ maybe we'll log e.Exception\r\n}\r\n<\/pre>\n
So first chance exceptions don’t tend to mean there’s problems within your code however using async\/await, especially with void async methods you may find first chance exceptions are the a precursor for an unhandled exception from one of these methods.<\/p>\n
If you check out Jon Skeet’s answer on stackoverflow to Async\/await exception and Visual Studio 2013 debug output behavior<\/a> he succinctly describes the problems that can occur with exception handling in async\/await code.<\/p>\n
To use this great quote “When an exception occurs in an async method, it doesn’t just propagate up the stack like it does in synchronous code. Heck, the logical stack is likely not to be there any more.”. With the async\/await on a Task, the task itself contains any exceptions, but when there is no task, when we’re async\/await on a void method, then there’s no means to propagate any exceptions. Instead these exceptions are more likely to first appear as First Chance exceptions and then unhandled exceptions. <\/p>\n
See also https:\/\/msdn.microsoft.com\/en-us\/magazine\/jj991977.aspx<\/p>\n","protected":false},"excerpt":{"rendered":"
Note: This post was written a while back but sat in draft. I’ve published this now, but I’m not sure it’s relevant to the latest versions etc. so please bear this in mind. You’ll often see First Chance exceptions in the output window of Visual Studio without them actually causing any problems with your application, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[49,3],"tags":[],"class_list":["post-3264","post","type-post","status-publish","format-standard","hentry","category-net","category-c"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/3264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/comments?post=3264"}],"version-history":[{"count":5,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/3264\/revisions"}],"predecessor-version":[{"id":9599,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/3264\/revisions\/9599"}],"wp:attachment":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/media?parent=3264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/categories?post=3264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/tags?post=3264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}