-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to show input arguments when :ret spec fails. #22
Comments
Hey! Thanks for making this issue. I agree that this would be a good thing to have. I'm not too interested in making it optional/configurable though, since nothing else we have is along those lines and I'd only want to add it IFF it's useful for, or at least not detrimental to, everyone. I do wonder if this would break some functionality in libraries like expound. @bhb, what do you think? Furthermore, are you open to accommodating this additional info, if present, for expound's output? |
I’m on vacation without my laptop so I can’t look at this in detail right now, but off the top of my head, I don’t think this would break expound as long as this new data is an expansion of the existing explain-data. If this info was present, I would display it in expound, I think. The only wrinkle I see is that this could potentially print out a lot of output if the inputs to the function are large data structures. I can’t think of a sensible way to shrink the output but perhaps this isn’t a big deal. |
I had forgotten that expound already prints out the function arguments if the
I haven't received any complaints about this, so I'm inclined to think that it's not a problem in practice to print out the arguments. So, if orchestra added this information to the explain-data, it should not be a big problem to print it in Expound. |
@jeaye Just wanna check if this is something that could be implemented anytime soon. |
Often, I'd find useful if orchestra could report input arguments for a function when the
:ret
spec fails.That is not just the report the
:ret
spec failure (a return value) but also the input (which obviously passed the:args
spec) from which the return value was computed.Is this something that you think could be useful for others too?
Is there a reasonable way to have it implemented as an optional/configurable behavior?
The text was updated successfully, but these errors were encountered: