-
Notifications
You must be signed in to change notification settings - Fork 29
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
Update handling of argument errors #97
Update handling of argument errors #97
Conversation
Neat, this looks like a sound approach! 👍🏻 Ideally:
|
@sunny I have added the changes. Please take a look when you have time. The changes mainly concern the |
@sunny I propose to update the comments on the code and edits :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mostly left comments pertaining to defending against missing keys when gathering values from advanced inputs. Mostly around :message
, but we might want to validate the presence of both it and :is
as well.
return add_argument_error( | ||
message, | ||
input_key: @input_key, | ||
actor: self.class, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if someone sets the value of default: {}
? Should we have a fallback?
return add_argument_error( | |
message, | |
input_key: @input_key, | |
actor: self.class, | |
) | |
if message.nil? | |
return "The \"#{@input_key}\" input on \"#{@actor}\" is missing" | |
else | |
return add_argument_error( | |
message, | |
input_key: @input_key, | |
actor: self.class, | |
) | |
end |
|
||
def define_inclusion_and_message | ||
if @inclusion.is_a?(Hash) | ||
@inclusion.values_at(:in, :message) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like ServiceActor::Checks::DefaultCheck
, what should we do in the vent that someone doesn't include the :message
key in the advanced mode hash?
|
||
def define_check_and_message_from(nested_check_conditions) | ||
if nested_check_conditions.is_a?(Hash) | ||
nested_check_conditions.values_at(:is, :message) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just pointing out that we might want to handle situations where the :message
key isn't present, as mentioned in other comments.
end | ||
|
||
def check | ||
return unless @value.nil? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be making this check? What if the argument is allow_nil: false
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this place everything should be correct. If false
is passed, then the input will expect a value.
|
||
def define_allow_nil_and_message_from(allow_nil) | ||
if allow_nil.is_a?(Hash) | ||
allow_nil.values_at(:is, :message) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One (second to) last comment to point out that we might want to defend against missing :message
keys.
input_key: input_key, | ||
actor: actor, | ||
type_definition: conditions, | ||
given_type: result[input_key], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we give the actual class object instead of the value?
given_type: result[input_key], | |
given_type: result[input_key].class, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It breaks behavior. This is not the purpose of this PR.
def define_types_and_message | ||
if @type_definition.is_a?(Hash) | ||
@type_definition, message = | ||
@type_definition.values_at(:is, :message) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last callout about defending against a missing :message
key.
@Buzzkill-McSquare Thanks for the comments. These areas really need to be improved. I will try to improve it, but as part of a separate PR. In this PR, I'm trying to replace a slightly different functionality. |
Got it. I wasn't entirely sure of the scope of the changes here, sorry for suggesting some creep. |
@sunny Look, please, once again at the code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work. Sounds like we can continue in this direction 👍🏻
Good points raised by @Buzzkill-McSquare as well about the empty message
arguments, but that should probably be another PR on top of this once this is merged.
7aaed33
to
3148f46
Compare
Hi Anton! In regard to Could you have a look at what I committed and let me know what you think? |
Hello! I like this. It's much easier and better with this. Thanks 🙂 |
This has been released under v3.6.0 🎉 Thanks a lot for your contribution @afuno, this is a much better way of handling errors! Happy holidays ✨ |
@sunny Thanks. Happy Holidays to you too 🎆 |
This PR updates the argument error handling.
All errors are put into an array one by one.
Within this PR, only the first error is raised. This preserves the underlying logic when working with services.
The purpose of this PR is to solve the problem of ignoring the first checks in favor of the last. An example is presented here: #95