locked
WinJS Promise causes exception - even if exception is handled

    Question

  • WinJS.Promise is causing unknown exceptions and stops the app. The app already has a try..catch block, but it doesn't help.

    Below is the code snippet. If I try an invalid rss feed url in below code, it crashes the app. The try..catch doesn't seem to help.

    document.addEventListener("DOMContentLoaded", initialize, false);
    
    function initialize() {
    
        feedGetAsync("http://blogs.msdn.com/b/b8/atom.aspx-fail").then(
                        function (ev) { console.log("success");},
                        function (ev) { console.log("failure"); },
                        function (ev) { console.log("progress"); });
    }
    
    function feedGetAsync(url) {
        
        return new WinJS.Promise(function (completed, failed, progress) {
            try {
    
                var uri = new Windows.Foundation.Uri(url);
                var synd = new Windows.Web.Syndication.SyndicationClient();
                synd.bypassCacheOnRetrieve = true;
                progress();
                synd.retrieveFeedAsync(uri).done(function (f) {
                    progress();
                    completed();
                }, function () {
                    failed();
                });
            }
            catch (ex) {
                failed();
            }
    
        });
    
    }


    • Edited by joemetro Monday, June 18, 2012 8:26 PM syntax error
    Monday, June 18, 2012 6:35 PM

Answers

  • Looks like I had to go under Visual Studio - Debug - Exceptions and click check mark for user "user-unhandled" .

    default seems to be to break.

    • Marked as answer by joemetro Monday, June 18, 2012 11:39 PM
    Monday, June 18, 2012 11:39 PM
  • Yes, that's what I thought might be happening.  User-unhandled exceptions are meant to only be displayed if an exception is handled in non-user code (such as the generated WinRT promise wrapper), and there isn't a handler for that exception in user code. Unfortunately, this has proven to be noisy when debugging promises. We are taking that feedback into account going forward.
    Tuesday, June 19, 2012 2:23 AM

All replies

  • See your other post.  If there is a syntax error the code cannot continue.  If that is not it, let us know!

    Jeff Sanders (MSFT)

    Monday, June 18, 2012 7:22 PM
    Moderator
  • I corrected the semicolon syntax error, same result. 

    I verified by copy-pasting above code into a blank project, and checking log messages.

    Monday, June 18, 2012 8:26 PM
  • .done is not guaranteed to throw unhandled exceptions synchronously, so they may not be caught by your try...catch block.  If you want to catch all errors, including those that might be thrown in the completed handler, you will probably want to add your error handler such that it is in the lowest call in the chain. So, something like this:

    synd.retrieveFeedAsync(uri).then(function(f) {

        progress();

        completed();

    }).done(null, function () {

        failed();

    });

    Monday, June 18, 2012 9:53 PM
  • I modified my code above with your recommendation. Still same problem. Can you please copy-paste the above code snipped into a blank javascript metro project, and quickly run it. (with your suggested changes above included) ? I am still seeing app crash. thanks, appreciate help!

    Monday, June 18, 2012 10:18 PM
  • I don't see a crash with your code or with mine.  Are you getting an exception dialog?  If so, what does it say?  If you continue after the exception, does your app actually crash?
    Monday, June 18, 2012 10:57 PM
  • if I click continue, it proceeds without app crash. But how do I avoid this clicking to continue. Is there a way to disable it. thanks.
    Monday, June 18, 2012 11:28 PM
  • Looks like I had to go under Visual Studio - Debug - Exceptions and click check mark for user "user-unhandled" .

    default seems to be to break.

    • Marked as answer by joemetro Monday, June 18, 2012 11:39 PM
    Monday, June 18, 2012 11:39 PM
  • Yes, that's what I thought might be happening.  User-unhandled exceptions are meant to only be displayed if an exception is handled in non-user code (such as the generated WinRT promise wrapper), and there isn't a handler for that exception in user code. Unfortunately, this has proven to be noisy when debugging promises. We are taking that feedback into account going forward.
    Tuesday, June 19, 2012 2:23 AM