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

Make sure key in antl.formatMessage() is a string before splitting, return default value if not #37

Closed
wants to merge 2 commits into from

Conversation

lrenninger
Copy link

Proposed changes

Check to make sure that the key being passed to antl.formatMessage() is a string before using .split() on it in order to prevent errors/exceptions trying to use a string function on a non-string.

If the key is not a string, return the default value. This seems appropriate given the fact that if the key is not found, the default is returned.

Types of changes

What types of changes does your code introduce?

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

  • I have read the CONTRIBUTING doc
  • Lint and unit tests pass locally with my changes
  • I have added tests that prove my fix is effective or that my feature works.
  • I have added necessary documentation (if appropriate)

Further comments

This is a relatively small change to fix a bug and avoid having to try/catch around instances of antl.formatMessage() in cases where the key may be sourced from a variable.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.05%) to 95.973% when pulling 2c33ce2 on lrenninger:develop into 0b0eff2 on adonisjs:develop.

@RomainLanz
Copy link
Member

Should we throw an exception instead of returning null when the key isn't a string?

What do you think @thetutlage?

@thetutlage
Copy link
Member

Yeah returning default value is not the correct behavior. We should raise exception here, since you are misusing the method.

* Make sure key is a string before attempting to split it
*/
if (typeof (key) !== 'string') {
return defaultValue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to throw an exception instead of returning the default value.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An empty string returns the default value, so would it be acceptable to return the default value if the key is null or undefined and only throw an exception if the key is not a string/undefined/null?

This would keep people from having to guard against null or replace it with "" in every case where formatString() is used on a variable containing a key.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you don't have a key, then you shouldn't be calling this method at all. Guarding against these sort of use cases is not a good practice, the application code to handle the inconsistencies itself.

Also I am not sure how come you can have the defaultValue but don't have the key?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was counting formatValue()'s default of null (via get()'s default) as the defaultValue in that case.

The suggested change makes sense from the point of view of having the user do all of the guarding logic in application code. I was missing that context and tried to fill it in from other behavior, specifically what happens with an empty string key.

If the lack of a key is intended to be an error case, it seems like an empty string key should also throw an exception. Is that correct?

Currently, if you provide an empty string key, you will get the defaultValue back due to the use of _.get() with both group and messageKey being null. I added a test to confirm this behavior locally.

I just want to make sure this ends up behaving as intended when I make the changes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitively better to throw an exception there. Could you make the change?

@thetutlage thetutlage closed this Jul 10, 2019
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

4 participants