[racket] Better discoverability for errortrace

We were having a discussion today in the Northeastern lab about how the
Racket stack traces sometimes don't give enough information, and the
solution to the problem (errrortrace) is not very discoverable if you're
not using DrRacket.

Here's an example of the kind of case I mean:

$ racket -t jpg.rkt
Assertion failed on #f
  context...:
   do-it
   /Users/acobb/programs/jpg-parse/jpg.rkt:402:2: for-loop
   decode-jpeg
   /Users/acobb/programs/jpg-parse/jpg.rkt: [running body]

$ racket -l errortrace -t jpg.rkt
Assertion failed on #f
  errortrace...:
   /Users/acobb/programs/jpg-parse/jpg.rkt:126:16: (assert #f)
   /Users/acobb/programs/jpg-parse/jpg.rkt:363:36: (huff-dc-decode dc-tree
bits)
   /Users/acobb/programs/jpg-parse/jpg.rkt:407:37: (reader bits)
   <eliding for length>
  context...:
   huff-dc-decode
   do-it
   /Users/acobb/programs/jpg-parse/jpg.rkt:406:5: for-loop
   /Users/acobb/programs/jpg-parse/jpg.rkt:402:2: for-loop
   decode-jpeg
   /Users/acobb/programs/jpg-parse/jpg.rkt: [running body]


To solve the discoverability issue, what would people think of putting a
message like "If this information is not sufficient, try errrortrace with
racket -l errortrace -t <prog>" after the default trace? Also, can anyone
think of a way to programmatically detect when a trace is not informative
enough and only display the message in those cases? I haven't looked into
the feasibility of this myself; it's just an idea that came up during our
discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140929/675e9ee4/attachment.html>