The message "Couldn't satisfy such-that predicate after <n> tries" isn't enough to understand which generator failed when generating a structure with such-that generators in multiple locations within the structure. The attached patch adds a :last-generated-value to the ex-data of the error. Ideally we'd also be able to see the predicate that failed, but that would require a much more invasive change and adding the generated value is very low hanging fruit and can be helpful in many cases, so I think this is a good start.
The exception thrown by such-that (on master, not 0.9.0) contains in the ex-data the generator that failed – so you should be able to pull that generator out of the ex-data and sample it, which gives you more information, theoretically, than just the last failing value.
I'm closing this since I argued for its being unnecessary and there hasn't been a counterargument.
I'm happy to discuss further, just wanted to clean up the open tickets.
Apologies for not responding sooner, Gary! If I have a counter argument (which I don't right now) I'll follow up w/ a new ticket.
Hey Gary - I finally ran into this again, pulled out the generator and sampled it and got a bunch of insts. The problem I have now is that this is a deeply nested structure with multiple insts at multiple levels, so I still have to do a bunch of spelunking to find the real culprit. I do like the idea of having the generator in hand, but more context about the generator to help me pinpoint the problem spec would be most helpful. Thoughts?
By "more context" do you mean "the last-generated value would have helped me figure this out faster", or are you wondering about new ideas?
such-that also has the option to customize its error message when you create the generator, and this was added so that spec would be able to give clearer error messages for spec-generated generators. Does that fit your use case or are you doing something different?