d-language-server / dls

A Language Server implementation for D
http://dls.dub.pm
106 stars 15 forks source link

Temporary fix for crashing #12

Closed spikespaz closed 5 years ago

spikespaz commented 5 years ago

When a part of DLS fails, such as parsing the file, this is likely not an error that should be considered fatal. Most of the time the file is just incomplete and the parser crashed reading it, and that shouldn't affect your workflow. Just silently ignore the error, and wait for the next file save to parse again. For now, keep the old information from the previous parse.

What about just ignoring parsing errors? As far as I am concerned, the only things that should break DLS completely is formatting. Not even symbol information (IntelliSense).

I don't need that stupid output log popping up when I forget a brace on a block, I shouldn't have to reload VS Code just to get it working again. Don't bother the user with fatal error messages that aren't DLS's fault.

Edit: Since people are probably going to throw fits saying "fatal errors are fatal and shouldn't be ignored", make a setting called "steamroll errors" kind of like FuckItJS. That way people that want to be bothered by annoying unnecessary crash messages still can be.

LaurentTreguier commented 5 years ago

Technically there is no way to determine whether an error comes from parsing or something else. AssertErrors are very probably only going to be thrown by libdparse, but the correct way to do it would be to introduce an exception type in libdparse like ParseException instead of ignoring errors.

As you say, errors as supposed to be fatal, and the problem is that libdparse uses errors for something that is not fatal; and that's what might need fixing.

I reckon a lot of errors are also due to the fact that I'm still using libdparse 0.8.x, since dfmt hasn't seen a new release with 0.9.x.

Also why should formatting be allowed to break DLS ?

spikespaz commented 5 years ago

@LaurentTreguier Well could we have an opt-in to steamroll dfmt and libdparse's errors? And I didn't say formatting should be allowed to break DLS, I don't think it should be allowed to break DLS. That's what I would like to see fixed, or at least suppressed.

LaurentTreguier commented 5 years ago

Catching errors is still really ugly though. But since it could be helpful (at least until I can upgrade dfmt and libdparse), I'll see if I can do it.

As far as I am concerned, the only things that should break DLS completely is formatting

That does imply formatting could break DLS :/

spikespaz commented 5 years ago

@LaurentTreguier Yes it's ugly, but it should be a temporary measure. I would rather use some bad practices than have the server crash every time I make a typo.

And yeah I see what you're getting at, not sure what I was thinking when I worded that sentence.

LaurentTreguier commented 5 years ago

Version 0.14.3 will be available in a bit less than an hour. Both the VSCode extension and the Atom package now have a d.init.catchErrors setting that will catch any and all errors blindly.

spikespaz commented 5 years ago

@LaurentTreguier Thanks for implementing this! Hopefully it won't be needed much longer.