Skip to content
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

Merged
merged 23 commits into from
Dec 29, 2022

Conversation

afuno
Copy link
Contributor

@afuno afuno commented Oct 23, 2022

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

lib/service_actor/checkable.rb Outdated Show resolved Hide resolved
@sunny
Copy link
Owner

sunny commented Oct 24, 2022

Neat, this looks like a sound approach! 👍🏻

Ideally:

  • each check class could be able to tell by itself if it needs to be applied or not depending on the input key (and other options), rather than having the condition inside the general Checkable
  • we can reduce the duplication of all the conditions down to an array of available check classes
  • we can re-use the same logic on inputs and outputs

@afuno
Copy link
Contributor Author

afuno commented Nov 5, 2022

@sunny I have added the changes. Please take a look when you have time. The changes mainly concern the Checkable class, where I have improved the look of the code, also considering your recommendations.

lib/service_actor/checkable.rb Outdated Show resolved Hide resolved
lib/service_actor/checkable.rb Outdated Show resolved Hide resolved
lib/service_actor/checkable.rb Outdated Show resolved Hide resolved
lib/service_actor/checkable.rb Outdated Show resolved Hide resolved
lib/service_actor/checkable.rb Show resolved Hide resolved
lib/service_actor/checks/default_check.rb Show resolved Hide resolved
lib/service_actor/core.rb Outdated Show resolved Hide resolved
lib/service_actor/core.rb Outdated Show resolved Hide resolved
@afuno
Copy link
Contributor Author

afuno commented Nov 6, 2022

@sunny I propose to update the comments on the code and edits :)

Copy link

@Buzzkill-McSquare Buzzkill-McSquare left a 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.

Comment on lines +78 to +82
return add_argument_error(
message,
input_key: @input_key,
actor: self.class,
)

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?

Suggested change
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)

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)

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?

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?

Copy link
Contributor Author

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)

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],

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?

Suggested change
given_type: result[input_key],
given_type: result[input_key].class,

Copy link
Contributor Author

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)

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.

lib/service_actor/core.rb Outdated Show resolved Hide resolved
@afuno
Copy link
Contributor Author

afuno commented Nov 6, 2022

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

@Buzzkill-McSquare
Copy link

Got it. I wasn't entirely sure of the scope of the changes here, sorry for suggesting some creep.

@afuno
Copy link
Contributor Author

afuno commented Nov 26, 2022

@sunny Look, please, once again at the code.

Copy link
Owner

@sunny sunny left a 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.

lib/service_actor/checkable.rb Outdated Show resolved Hide resolved
lib/service_actor/checkable.rb Outdated Show resolved Hide resolved
@afuno afuno marked this pull request as ready for review December 7, 2022 15:48
@sunny sunny force-pushed the feature/collection_of_argument_errors branch from 7aaed33 to 3148f46 Compare December 20, 2022 09:34
@sunny
Copy link
Owner

sunny commented Dec 20, 2022

Hi Anton! In regard to instance.send(:raise_accumulated_errors I have pushed a few suggestions on your branch. I think moving raise_accumulated_errors out of the core this makes the code simpler with less dependencies between the core and the other parts. Also, raising errors for inputs and outputs are kept together.

Could you have a look at what I committed and let me know what you think?

@afuno
Copy link
Contributor Author

afuno commented Dec 20, 2022

Hi Anton! In regard to instance.send(:raise_accumulated_errors I have pushed a few suggestions on your branch. I think moving raise_accumulated_errors out of the core this makes the code simpler with less dependencies between the core and the other parts. Also, raising errors for inputs and outputs are kept together.

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 🙂

@sunny sunny merged commit 0c90316 into sunny:main Dec 29, 2022
@sunny
Copy link
Owner

sunny commented Dec 29, 2022

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 ✨

@afuno
Copy link
Contributor Author

afuno commented Dec 29, 2022

@sunny Thanks. Happy Holidays to you too 🎆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants