On 6/04/16 12:47 pm, Luke Church wrote:
Based on observational studies, I've generally recommended to the Dart
<http://www.dartlang.org/> team that the verbose errors state:
- *What happened* (e.g. File 'stuff, ln 43:' class B doesn't implement
- *Why it is a problem* (e.g. class B extends class A, which has an
abstract method foo. This means that class B doesn't have an
implementation of foo)
- *What the user can do next* (e.g. consider implementing foo, or
making class B abstract)
If I may add an anecdote, I once used a programming system
whose authors had put enormous effort into writing "helpful"
error messages. But I found them infuriating. Much of the
text would explain what the program thought you were trying
to do, but it was almost always wrong about that.
Take this particular example as an example: maybe the real
problem is that the student was trying to call food(), not
foo(), in which case advice to make B abstract is worse than
An error is detected when the system expects something and
something else happens. Saying clearly *where* the error
was is important (and I know my own programs are not very
good at this), as is saying what the system expected and what
it thinks it got.
In the Haskell world, one group went to the trouble of building
a whole new system called Helium, in part so that they could
provide human-friendly error messages.
You received this message because you are subscribed to the Google Groups "PPIG
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.