Distinguish between cases "resolver doesn't exist" and "resolver does exist, but fails" when resolving logical locations - #2901
Conversation
The new `tryResolve` is the same as the existing `safeResolve`, except `tryResolve` propagates both `IOException`s and unchecked exceptions to the caller, whereas `safeResolve` catches and ignores all exceptions.
…e *already* allows `IOException`s to be thrown (i.e., callers of those methods should already be sufficiently resilient)
d5a8856 to
046db25
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2901 +/- ##
=======================================
Coverage 45% 45%
- Complexity 6799 6811 +12
=======================================
Files 843 844 +1
Lines 68828 68824 -4
Branches 10030 10028 -2
=======================================
+ Hits 31385 31420 +35
+ Misses 35054 35012 -42
- Partials 2389 2392 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
DavyLandman
left a comment
There was a problem hiding this comment.
I think this PR is doing too little.
It should also be dealing with the case of a resolver that is not specific to an authority, but deal with case where it says to resolve all kinds of authorities, but sometimes fail.
The original issue with mkDirectory(|project://not-existing|) is a nice example of this. (but I understand that there are 2 project resolvers at play, and they make debugging/developing this feature messy)
DavyLandman
left a comment
There was a problem hiding this comment.
Looks good, some small semantic/perf changes I propose.
…n resolution fails
|



Fixes usethesource/rascal-language-servers#1193