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 method foo) - *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
useless.

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 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ppig-discuss+unsubscr...@googlegroups.com.
To post to this group, send an email to ppig-discuss@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to