-
-
Notifications
You must be signed in to change notification settings - Fork 279
Added new "exception" optional parameter #344
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
Conversation
A custom exception can be supplied to the guard clause methods to throw it instead of the default exception
A custom exception can be supplied to the guard clause methods to throw it instead of the default exception
…rdClauses into custom-exception
Also fixed a few named arguments missing from method calls that i found through running the tests
Awesome thanks! I'll try to get this out tomorrow. |
It's a little weird that you're newing up the exception every time even if the guard doesn't throw. Seems like a Func where T:Exception would potentially be a better approach and then you only instantiate the exception as needed. Going to merge this and then check that out. |
I'm in the process of replacing the Exception parameter with a factory method that will produce the exception only when needed, which should be better performing and have fewer allocations. |
@ardalis how's this coming along? 😬 |
I started on it a while ago and then got busy with other things. You can see the WIP here: Basically I want to continue that pattern throughout before I create another release. Anyone want to help get this to the finish line? |
Maybe @UnleashedGH can...? 🤞 |
Maybe @canro91 can take a look... |
This new optional parameter can be supplied to the IGuardClause methods to throw the supplied exception instead of the default one in the method.
it's usage would be something like this:
the custom exception would only be thrown if exception relates to what the method checks and not thrown for param validation for the method itself
for instance, the custom exception would not be thrown here instead of ArgumentException because that validates the params (rangeFrom and rangeTo) for the method itself