locked
I keep getting this annoying error once in a while, and had to press debug again in order to work. How to fix it ?

    Question

  • The error code is:

    Exception was thrown but not handled in user code at line 183, column 5 in Function code
    
    0x80070002 - JavaScript runtime error: The system cannot find the file specified.
    
    If there is a handler for this exception, the program may be safely continued.

    Friday, July 13, 2012 3:30 PM

Answers

  • This is a "user-unhandled" exception thrown inside a WinRT promise (probably one of the async file APIs).  Errors thrown from async operations (like File not found) will always result in "user-unhandled" exceptions because they are not caught by any try/catch in user code.  We have received feedback that this causes promises to be very noisy at debug time, and are taking that into account going forward.

    To fix your immediate problem, you can disable "user-unhandled" exceptions for JS in the Debug->Exceptions dialog.

    (Update)

    I should have mentioned this earlier, but "user-unhandled" exceptions, especially those from promises, can be safely continued if you have an error handler hooked up to that promise.  They are intended to provide a first-chance exception experience for errors the might be swallowed by library code, so information about the exception can be surfaced to the developer.

    Friday, July 13, 2012 4:23 PM

All replies

  • This is a "user-unhandled" exception thrown inside a WinRT promise (probably one of the async file APIs).  Errors thrown from async operations (like File not found) will always result in "user-unhandled" exceptions because they are not caught by any try/catch in user code.  We have received feedback that this causes promises to be very noisy at debug time, and are taking that into account going forward.

    To fix your immediate problem, you can disable "user-unhandled" exceptions for JS in the Debug->Exceptions dialog.

    (Update)

    I should have mentioned this earlier, but "user-unhandled" exceptions, especially those from promises, can be safely continued if you have an error handler hooked up to that promise.  They are intended to provide a first-chance exception experience for errors the might be swallowed by library code, so information about the exception can be surfaced to the developer.

    Friday, July 13, 2012 4:23 PM
  • but I didn't use any promise. When I press break, and then I debug again, it works. Then a couple of tests, it apprears again, then I had to press break button, then debug again, it works. Not a bug I guess ?
    Friday, July 13, 2012 4:45 PM
  • Are you using any of the asynchronous Windows APIs (getFileAsync etc.)?  Those are projected as promise objects.  So, even if you're not explicitly using WinJS.Promise, you could be using promises projected from WinRT.

    It is not a bug, but as I mentioned in my earlier reply, it is a known pain point for debugging promise objects.

    Friday, July 13, 2012 5:03 PM
  • I know what you're saying, but I did not use any promise. Here is an example of the code:

    It works, but it shows that error, I had to press break, then I debug again, it works immediately, I did not change anything. It just simply don't work then work, weird:

    (function () {
        "use strict";
    
        var app = WinJS.Application;
        var activation = Windows.ApplicationModel.Activation;
        WinJS.strictProcessing();
    
        app.onactivated = function (args) {
    
            if (args.detail.kind === activation.ActivationKind.launch) {
    
                if (args.detail.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
    
                    // Newly started program, initialize variables.
                    
                    var html_flyout = $('<div><h1>heading</h1><p>paragraph</p><button>a</button></div>');
                    $('#body1').append(html_flyout);
                    var flyout = new WinJS.UI.Flyout(html_flyout[0], {});
                    flyout.show(html_flyout.get(0), 'right','center');
    
                } else {
    
                    // This application has been reactivated from suspension. Restore application state here.
                }
                args.setPromise(WinJS.UI.processAll());
            }
        };
    
        app.start();
    })();

    Friday, July 13, 2012 5:40 PM
  • the ONLY promise I used is "args.setPromise(WinJS.UI.processAll());" . it then gives the error:

    Exception was thrown but not handled in user code at line 183, column 5 in Function code

    0x80070002 - JavaScript runtime error: The system cannot find the file specified.

    If there is a handler for this exception, the program may be safely continued.

    I then press break, then I stop debug, then I press debug again, it then works. I did not change anything, I just debug-fail-press Debug again- success.

    Friday, July 13, 2012 5:42 PM
  • It happens quite a lot, in a random chance, sometimes it does, sometimes it doesn't.
    Friday, July 13, 2012 5:42 PM
  • Interesting.  It might be something in the WinJS code that's hitting the File Not Found error. I would hope the callstack would be able to tell you where it's coming from.

    Regardless of the source of the error, however, the behavior you're describing is expected.  This is a "user-unhandled" exception, so it is similar to a first-chance exception experience. If you break and then continue, or simply choose continue in the exception dialog, execution should continue.  When you hit this error, it isn't a failure, exactly. It is an error that is going to be caught and potentially swallowed by library code.  In this case in particular, since you did not make the call that triggered this error directly, and since it is a file not found exception, it is likely the library code (presumably WinJS in this case) is able to handle the error and continue execution.

    Have you tried diabling "user-unhandled" exceptions in the exceptions dialog? That should keep these messages from popping up all the time.

    Friday, July 13, 2012 6:20 PM