Bump. Okay if I make a pull request to make ‘match’ exceptions transparent? I see that all of the ones listed in 10.2.5 are transparent.
John > On Apr 27, 2016, at 3:08 PM, John Clements <cleme...@brinckerhoff.org> wrote: > > >> On Apr 27, 2016, at 3:01 PM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> >> wrote: >> >> The exceptions raised by `match` are indeed not transparent. But I >> don't understand why they need to be in order for the handin server to >> handle them properly. > > (caveat: this is my reading of the code below) > > The handin server wants to add information to the exn-message part, in order > to indicate what handin test triggered the error. > > Doing this involves converting the exception to a vector, adding text to the > message part, and then reassembling and re-raising the error. The code below > therefore bails out when either “skipped?” turns out to be true or when one > or when struct->vector produces a vector with opaque fields. > > This doesn’t appear to be a problem for any of the other exceptions that the > handin server encounters (well, this is the first time I’ve seen this > problem, anyhow). > > I can hack the handin server to treat match exceptions specially, but that > definitely doesn’t seem like the right solution. > > 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))) > >> >> Sam >> >> On Wed, Apr 27, 2016 at 5:58 PM, 'John Clements' via Racket Users >> <racket-users@googlegroups.com> wrote: >>> >>>> On Apr 22, 2016, at 1:47 PM, 'John Clements' via Racket Users >>>> <racket-users@googlegroups.com> wrote: >>>> >>>> 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? >>> >>> Okay, answering my own question and asking another: >>> >>> The fundamental reason for the existence of this logic is that the >>> handin-engine is trying to be careful, and modify exceptions that can >>> safely be reconstructed. If the “skipped” value is #t, or if one or more of >>> the values in the structure are opaque, this is impossible. At this point, >>> the handin engine just throws up its hands and decides to follow the >>> hippocratic oath, “first do no harm,” and let the exception continue as is. >>> >>> So, this leads to a different question: *why* is the match exception >>> different from all the other exceptions? Based on my reading of the >>> struct-info documentation, it appears that the ‘match’ form constructs >>> exceptions whose inspector is not the current one, or perhaps that it fails >>> to declare itself as transparent. >>> >>> My guess is that this is just an oversight, and that a ‘match’ exception >>> should be just as transparent as, say, a division by zero exception. Here’s >>> code that illustrates the difference: >>> >>> #lang racket >>> >>> (with-handlers ([exn:fail? >>> (λ (exn) >>> (struct-info exn))]) >>> (/ 1 0)) >>> >>> (with-handlers ([exn:fail? >>> (λ (exn) >>> (struct-info exn))]) >>> (match 13 >>> ['a 4])) >>> >>> So, here’s my question: >>> >>> Is there a good reason for the difference between the `match` exception >>> (skipped is #t) and the division-by-zero exception (skipped is #f) ? >>> >>> John >>> >>> >>> >>> >>> -- >>> 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. > -- 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.
