I believe that ERR_FILE_CANT_OPEN is meant to convey that the file exists, but cannot be opened (e.g. no read permission, or it's indeed corrupted). So it would be worth tracking where this error is (wrongly?) returned.

Still, if a dependency is corrupted, the scene should open as if it was missing. The only unrecoverable case should be when the scene itself can't be loaded.

Should we consider printing unexpected error code without returning early, so loading a scene always recovers gracefully from a broken dep?

I tried looking for the source of invalid error, but the code is too tangled >_> It comes from some thread function.

Should we consider printing unexpected error code without returning early, so loading a scene always recovers gracefully from a broken dep?

Not sure what do you mean by that. The condition I modified makes the method not return. I could print the error if it's in the list of exceptions, but loading the scene already fills output with errors, so I think it's clearly communicated.

Nevermind, I found the source:

Not sure if we should change those, maybe. We need to harmonize our error reporting so that we use errors more purposely if we have checks that rely on specific error codes.

Either way, for the time being I think this PR makes it better.

Thanks!

Cherry-picked for 4.2.2.