Closed spikespaz closed 5 years ago
Technically there is no way to determine whether an error comes from parsing or something else. AssertError
s 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 ?
@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.
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 :/
@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.
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.
@LaurentTreguier Thanks for implementing this! Hopefully it won't be needed much longer.
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.