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 [email protected].
For more options, visit https://groups.google.com/d/optout.
