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.)
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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.
