{"id":2584,"date":"2022-08-30T15:26:05","date_gmt":"2022-08-30T15:26:05","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2014\/02\/04\/prevent-webbrowser-control-from-swallowing-exceptions-collection-of-common-programming-errors\/"},"modified":"2022-08-30T15:26:05","modified_gmt":"2022-08-30T15:26:05","slug":"prevent-webbrowser-control-from-swallowing-exceptions-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2022\/08\/30\/prevent-webbrowser-control-from-swallowing-exceptions-collection-of-common-programming-errors\/","title":{"rendered":"Prevent WebBrowser control from swallowing exceptions-Collection of common programming errors"},"content":{"rendered":"

I’m using the System.Windows.Forms.WebBrowser<\/code>, to make a view a-la Visual Studio Start Page. However, it seems the control is catching and handling all exceptions by silently sinking them! No need to tell this is a very unfortunate behaviour.<\/p>\n

void webBrowserNavigating(object sender, WebBrowserNavigatingEventArgs e)\n{\n    \/\/ WebBrowser.Navigating event handler\n    throw new Exception(\"OMG!\");\n}\n<\/code><\/pre>\n
The code above will cancel navigation and swallow the exception.<\/p>\n
void webBrowserNavigating(object sender, WebBrowserNavigatingEventArgs e)\n{\n    \/\/ WebBrowser.Navigating event handler\n    try\n    {\n        e.Cancel = true;\n        if (actions.ContainsKey(e.Url.ToString()))\n        {\n            actions[e.Url.ToString()].Invoke(e.Url, webBrowser.Document);\n        }\n    }\n    catch (Exception exception)\n    {\n        MessageBox.Show(exception.ToString());\n    }\n}\n<\/code><\/pre>\n
So, what I do (above) is catch all exceptions and pop a box, this is better than silently failing but still clearly far from ideal. I’d like it to redirect the exception through the normal application failure path so that it ultimately becomes unhandled, or handled by the application from the root.<\/p>\n
Is there any way to tell the WebBrowser<\/code> control to stop sinking the exceptions and just forward them the natural and expected way? Or is there some hacky way to throw an exception through native boundaries?<\/p>\n
    \n
  1. \n
    My best bet why it happens is because there is a native-managed-native boundary to cross. The native part doesn’t forward the managed exceptions correctly and there is not much that can be done.<\/p>\n
    I am still hoping for a better answer though.<\/p>\n<\/li>\n
  2. \n
    I haven’t seen the browser eat exceptions, unless you mean script errors. Script errors can be enabled via the browser.ScriptErrorsSuppressed<\/code> property.<\/p>\n
    If you’re talking about real exceptions, not just script errors, can you show us some code that reproduces the problem? We’ve used the browser extensively and haven’t seen what you’re describing.<\/p>\n
    edit<\/em> the code sample wasn’t there when I asked for a code sample<\/p>\n<\/li>\n<\/ol>\n
    Originally posted 2014-02-04 02:06:54. <\/small><\/p>","protected":false},"excerpt":{"rendered":"
    I’m using the System.Windows.Forms.WebBrowser, to make a view a-la Visual Studio Start Page. However, it seems the control is catching and handling all exceptions by silently sinking them! No need to tell this is a very unfortunate behaviour. void webBrowserNavigating(object sender, WebBrowserNavigatingEventArgs e) { \/\/ WebBrowser.Navigating event handler throw new Exception(“OMG!”); } The code above […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2584","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/2584","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=2584"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/2584\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=2584"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=2584"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=2584"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}