Currently, the handin-server runs student expressions in an ‘eval’ which
intercepts errors and re-raises them with a message that includes the failing
expression. All good.
However, it doesn’t catch all of them. Specifically, if the exception contains
any values that are opaque to struct->vector, it gives up and re-raises the
exception as-is.
This turns out to cause a problem with “match” failures, which include such
values. This causes a problem for my students, because they’re unable to see
the text of the test cases that they failed.
It’s easy enough to hack around this in my code by re-wording ‘match’ failures
in the same way that wrap-evaluator does. In general, though, it seems like
there’s no good reason that ‘match’ failures shouldn’t go into the same bin as
division by zero, applying a non-function, and all of the other things that can
go wrong during evaluation.
In order to fix this, then, I’m trying to determine why this check exists: what
exceptions do you *not* want to re-word here?
John
(define ((wrap-evaluator eval) expr)
(define unknown "unknown")
(define (reraise exn)
(raise
(let-values ([(struct-type skipped?) (struct-info exn)])
(if (and struct-type (not skipped?))
(let ([vals (cdr (vector->list (struct->vector exn unknown)))])
(if (memq unknown vals)
exn
(apply (struct-type-make-constructor struct-type)
(format "while evaluating ~s:\n ~a" expr (car vals))
(cdr vals))))
exn))))
(with-handlers ([exn? reraise]) (eval expr)))
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
