Unable to open 'libintegers_patch.dart': Cannot read property 'create' of undefined.

I am not sure what caused this as I updated a few things in the mean time, but debugging now gives me a popup saying Unable to open 'libintegers_patch.dart': Cannot read property 'create' of undefined. when it hits an exception. I have everything pretty much on the newest version, but I can send version numbers if you want.

Something changed about the debugging interface as well because now I can see some kind of file tree when I start the debugger. However, somehow the debugger no longer pauses on uncaught exceptions. Instead it quits and prints some error the the debug output. I get:

loading test/all.dart:

ERROR: Failed to load "test/all.dart":
The getter 'isNotEmpty' was called on null.
Receiver: null
Tried calling: isNotEmpty

{stack trace in my project}

This could very well be an error with the test or analyzer package, but I am not sure to track down where it it coming from.

[DanTup]

I’ve made two changes:

1. If the path given to us by the VM does not exist on disk, return no source reference to VS Code (this will result in “Unknown Source” being shown in the call stack)
2. If the user clicks on a stack frame that we thought we had source for (dart: libs in this case) but the VM returns undefined, then we will reject the request with <source not available>. This causes VS Code to show that string as if it was the source code for the file (!) but at least it’s clear to the user what’s happened.

It’s not ideal that we’re not going to show source code here, but that’s not something I can fix in Dart Code. I’ve added comments to https://github.com/dart-lang/sdk/issues/33959 so if things can be improved there, hopefully they will 😃

[DanTup]

If you do manage to reproduce the libintegers_patch.dart issue

I did! It actually seems like a lot of things are broken when you break there - I’ve opened https://github.com/dart-lang/sdk/issues/33959 for some advice. Things seem ok if you break inside your own code, but if you use Break on all exceptions to break inside pub/test before it gets to your code, you get these weird things (I suspect some of it may be related to its being compiled snapshots?).

Actually, maybe it would be possible to ignore exceptions from the pub isolate even when ‘All exceptions’ is checked since usually you are still not interested in exceptions from pub (especially if some part is designed to use exceptions with catch). I can open a new issue on this if you think it is a good idea.

I do think that’s a reasonable idea, but it relies on us being able to tell when we’re breaking on an exception that will be caught versus one that won’t. Open an issue and we can do some investigation.