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. -- 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.
