> On May 4, 2016, at 2:24 PM, Eli Barzilay <e...@barzilay.org> wrote: > > On Wed, May 4, 2016 at 5:12 PM, John Clements <cleme...@brinckerhoff.org> > 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
