> On Mar 25, 2019, at 11:59 AM, James Platt <j...@biomantica.com> wrote:
>
>
> On Mar 23, 2019, at 5:49 PM, Greg Hendershott wrote:
>
>> But -- contract violations aren't like that. They're about some code
>> surprising some other code. I think the only hope here is, run the
>> code enough (before the user ever does) to flush out the bad code
>> assumptions and fix them. Realistically that means having enough
>> automated tests, and running them frequently enough (like on every
>> code commit, or at least push, and you can't merge to master if tests
>> don't pass, etc.).
>
> Yes, but contract violations are also, by definition, problems that have been
> anticipated. You may not know why a function is, for example, being passed a
> specific parameter that is the wrong data type or is empty when you said it
> should be non-empty but you do know that that is what happened. It's enough
> to go on for an error message. My hope was that contracts would provide a
> more granular set of predicates to test for each of the possible violations.
Your exception handlers may test a contract failure to any level. You can
specify this in the predicate part of with-handlers or via match on the exn
within the handler function. Regexp matching works well here.
— Mattthias
--
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.
