5 ms·
Sorry to self-promote a little but, but I just published a dev diary [1] for Eve, where I talk about a lot of the same ideals described here. For instance, the
by cmontella 10y ago
Sorry to self-promote a little but, but I just published a dev diary [1] for Eve, where I talk about a lot of the same ideals described here. For instance, the author writes:
> For brownie points, your compiler should explain why the programmer has encountered an error, and for the gold medal it should propose a solution.
This is exactly what we're trying to do with Eve. In one of the examples [2], I show an error that is met with a full explanation of what went wrong, a possible fix, and even a button that offers to fix the error.
On our philosophy toward errors, we've identified that they should be understandable (written in full plain English sentences), relevant (point to the root cause of the error, rather than incidental errors), and actionable (we provide the reason for the error, offer to automatically fix the error where possible, and teach the user why the error occurred and how to avoid it in the future.)
We're still in the early stages of handling errors, but this is at least how we're thinking about it.
[1] http://incidentalcomplexity.com/2016/08/03/july/ http://incidentalcomplexity.com/2016/08/03/july/
[2] http://incidentalcomplexity.com/images/errorExample.gif http://incidentalcomplexity.com/images/errorExample.gif
- cpeterso 10y agoOne advantage of non-human-readable error messages is that they are easier to Google. Microsoft's compiler warning and error messages all have unique error codes like C1234, which make them easier to find on sites like MSDN or Stack Overflow. https://msdn.microsoft.com/en-us/library/aa249862(v=vs.60).aspx https://msdn.microsoft.com/en-us/library/aa249862(v=vs.60).a...
- cmontella 10y agoThis is true, but at the same time I don't think having to resort to Googling an error is a good user experience in the first place. With Eve, we want to try and avoid that as much as possible.
- Klathmon 10y agoWell the 2 aren't mutually exclusive. Throw a unique error code in there, as well as a description on how to fix it.
- Jtsummers 10y agoERROR 832A: Line 42, missing semicolon, you probably won't a semicolon here: foo(); ^ Or something of the like. If the compiler knows the error, it knows what things might be missing. In the case of limited options it could predict and continue parsing. Then, with a more complex error, that error code is actually useful for googling or reviewing the compiler documentation.
- seanmcdirmid 10y agoOr one could just apply semicolon inference and emit a warning, allowing the code to still run, at least.
- taeric 10y agoThat would probably be a step backwards. I'm all for a debug mode that can let bad code in a running environment. It should not pass a build, though.
- seanmcdirmid 10y agoDepends if you are compiling/executing the code continuously or not during development. Old-style batch programming environments are already plenty of steps backwards.
- taeric 10y agoFair. I actually loved the feature of Eclipse where bad code would pseudo compile. I just worry heavily about anything that emits warnings. Most warnings, it seems, either should have been failures, or needed more powerful tooling to know why it was ok.
- Retra 10y agoWarnings are basically errors that don't halt compilation. You shouldn't have any of either in production code.
- douche 10y agoWhich is helpful iff they ever get around to documenting the error codes. I've had the unfortunate experience of dealing with a number of APIs that have that kind of an error code scheme, except the doc was autogenerated minimal shit, and there's apparently about a dozen people in the world that work on this stuff, so the google-fu doesn't turn up much.