> On May 4, 2016, at 2:24 PM, Eli Barzilay <[email protected]> wrote: > > On Wed, May 4, 2016 at 5:12 PM, John Clements <[email protected]> > wrote: >> >> So, I’d say this is basically an ergonomics issue. If we change this >> code to raise a new exception, then it might potentially confuse a >> handin-server-checker-writer, who expects (e.g.) to see a >> ‘exn:fail:contract:variable?’ but actually gets back a >> ‘exn:fail:handin-server?’. IIUC, clear documentation could resolve >> this. > > I have no opinion on breaking backward compatibility on expectations of > user-code (I might have some but I can adjust), but things like > `!defined`, `!bound`, and `!syntax` should definitely continue working > -- and it seems worse to fix them by looking at the exception message. > > Another option to fix it would be to make it keep doing what it does now > if the exceptions are transparent, and switch to some wrapper exception > otherwise. This way you're only breaking hypothetical code that expects > exceptions that make it fail now anyway, IOW -- there's no breaking... > (And also document the fact that not all of the builtin exceptions are > transparent, unless it's already done somewhere.)
IIUC, it sounds like both you and Sam are suggesting the same thing. I think this *could* cause backward incompatibility for the *probably empty* set of handin checkers that use tests for non-transparent exceptions, but I’m happy to make this change if it makes sense to you guys. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
