Rename `invalid` to... something else?

[Rich-Harris]

Describe the problem

One side-note from #7956: invalid(422, {...}) is natural, but invalid(500, {...}) — which you need to do in order to show inline error UI along with repopulated form values — feels a bit weird. The error isn't that the data was invalid, it's that something went wrong on the back end.

Describe the proposed solution

Rename it to something that covers both 4xx and 5xx errors:

• fail(status, data)
• failed(status, data)
• nope(status, data)

Suggestions welcome. (Note that we can't return error(status, data) because data must conform to App.Error in that case.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[amrnt]

halt(status, data)?

[sourcegr]

Boom(status, data)

[dummdidumm]

I like invalid, because it's a very good fit for 90% of use cases.

[smstromb]

+1 for failed(status, data)

[arackaf]

You could keep invalid as it is, but add a failed() which took only the error data, and returned a 500 for you. Ie

invalid(420, { status: "Too high" });

or

failed({ status: "Something broke }); // returns a 500 

[sourcegr]

on a second thought, I kind of regret the boom proposal due to some reasons.

• it feels a little cryptic
• it is kind of informal
• is used by hapi and it might bring confusion over time

So, I would rather recommend a more generic failure(status, data) instead of fail, failed

return failure(status, data) seems more natural

[scottBowles]

fauxpas, please.

Really though, I like either invalid or failure. I'm mostly ok with invalid because it describes how you're choosing to handle the error. The invalid function takes some backend reality and decides it will hand it to the client-side +page to handle it as a bad response, rather than as the +error page. If it wraps a 500 that seems fine to me because the 500 describes what went wrong, and the use of invalid describes how we're passing it forward. I could see failure too, and in any case ValidationError should probably be changed.

Alternatively, I could see changing error/invalid to something like panic/error to capture that one is disrupting the usual flow of your app and the other is passing on a bad message.

[sourcegr]

And while we 're at it, may I boldly suggest we revisit the naming for validationError, since this could also be an upstreamError or a connectivityError or someOtherReasonError

[sourcegr]

handlingError would also be a fits-both proposal, and also solves the interface naming problem for ValidationError; it is renamed HandlingError.

OK, I am going to shut up now :)

[cdcarson]

Keep invalid. This means what it says -- you have an invalid form that the user can fix in the context of the form itself. Overloading that with errors like

• "make sure your WiFi is in range" or
• "hey, bad actor, you can't launch the missile, you should never have even seen that button"

is IMO bad UX and bad DX.

The fact that 400 Bad Request and 403 Forbidden share a 4 is academic -- what matters is the difference in the business logic.

[kvetoslavnovak]

fail(status, data) sounds ok

[elliott-with-the-longest-name-on-github]

I like fail (failed feels wrong -- it would imply we should also have errored and redirected, which sound terrible). I like nope most of all, but I also know the serious-minded folk would hate it. 😆