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

Ensure errors thrown from submit handler are not silenced #3744

Merged
merged 1 commit into from
Jan 16, 2018

Conversation

10xjs
Copy link
Contributor

@10xjs 10xjs commented Jan 12, 2018

Fixes #3303

In the very likely case that an error is encountered during a submit callback we need to be able to reliably detect any failures.

This restores the correct behavior stated in the documentation:

Submits the form. [You'd never have guessed that, right?] Returns a promise that will be resolved when the form is submitted successfully, or rejected if the submission fails.

This will revert the change made in #3227, but throwing the error is a far better compromise that benefits a much larger set of redux-form users. It's possible to silence errors in your own code, but not possible to recover discarded errors from inside an isolated context in a lib.

Fixes redux-form#3303

In the very likely case that an error is encountered during a submit callback we need to be able to reliably detect any failures.

This restores the correct behavior stated in the [documentation](https://redux-form.com/7.2.0/docs/api/reduxform.md/#-code-submit-promise-code-):

> Submits the form. [You'd never have guessed that, right?] Returns a promise that will be resolved when the form is submitted successfully, or rejected if the submission fails.

This will revert the change made in redux-form#3227, but throwing the error is a _far better_ compromise that benefits a _much larger set_ of redux-form users. It's possible to silence errors in your own code, but not possible to recover discarded errors from inside an isolated context in a lib.
@codecov-io
Copy link

codecov-io commented Jan 12, 2018

Codecov Report

Merging #3744 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff           @@
##           master   #3744   +/-   ##
======================================
  Coverage     100%    100%           
======================================
  Files          70      70           
  Lines        1578    1578           
======================================
  Hits         1578    1578
Impacted Files Coverage Δ
src/createReduxForm.js 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 653aca4...62f667f. Read the comment docs.

@erikras erikras merged commit 58c4a05 into redux-form:master Jan 16, 2018
@erikras
Copy link
Member

erikras commented Jan 18, 2018

Published in v7.2.1.

@dave-irvine
Copy link

Hi @10xjs, @Erikas,

While I 100% agree with this pull, errors should not be swallowed, I'm wondering how we are supposed to consume the error thrown here?

At the moment the error I throw in asyncValidate is not handled anywhere and ends up in the console. I'd love to catch the error, but I can't find anywhere to catch what this change throws.

Any tips?

@10xjs
Copy link
Contributor Author

10xjs commented Mar 14, 2018

@dave-irvine I haven't used asyncValidate myself, but I believe that you are able to catch its errors with the onSubmitFail prop. (https://github.com/erikras/redux-form/blob/master/src/handleSubmit.js#L107)

@dave-irvine
Copy link

dave-irvine commented Mar 14, 2018

Hi @10xjs, unfortunately no matter what you do in onSubmitFail, https://github.com/erikras/redux-form/blob/master/src/handleSubmit.js#L109 rejects with the errors, which are then subsequently thrown by your change. :(

@10xjs
Copy link
Contributor Author

10xjs commented Mar 14, 2018

I wonder if we need a new onAsyncValidationFail prop?

@lock
Copy link

lock bot commented Jun 1, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Errors are being swallowed again, due to #3227
4 participants