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

Error handling default/standard object #6263

Closed
bluepuma77 opened this issue Aug 25, 2022 · 3 comments
Closed

Error handling default/standard object #6263

bluepuma77 opened this issue Aug 25, 2022 · 3 comments
Labels
Milestone

Comments

@bluepuma77
Copy link

Describe the problem

I would love to see an opinionated standardized error handling for SvelteKit.

For a year we have been building a B2B application with SvelteKit and IMHO it is missing a default/standard error object. In my view there are 3 kinds of errors that usually occur when using a shadow endpoint (sorry for old naming):

  1. Network not working
  2. Server not working (e.g. status 500)
  3. Input not working

It would be great to be able to handle all of those errors with a single default/standard error object.

Please be aware that besides the simple Twitter demos with a single input field and no error handling there are indeed some real applications out there. Those need multiple input fields, so can have multiple errors. Furthermore they need to do client and also server side validation to ensure data is not tampered with.

Describe the proposed solution

I would like to see a default/standard error object for the 3 cases mentioned above.

This is just an idea, this is not a real proposal. If no error, the error object is null or should not exist.

  1. Network error
    error: { status: '-1', name: 'NETWORK_ERROR', msg: 'Server could not be reached' }
  2. Server error
    error: { status: '500', name: 'HTTP_SERVER_ERROR', msg: 'Server returned internal error' }
  3. Input error
    error: { status: '200', name: 'FORM_INPUT_ERROR', msg: 'Invalid input' }

Case 3 doesn't really work that way because there might be multiple input errors. Furthermore the error object should be able to provide additional fields, for example the input field names

Input error (with input field name)
error: { status: '200', name: 'FORM_INPUT_ERROR', msg: 'Invalid input', props: { input: 'email' } }

Input error (with input field name, multiple errors)

error: { status: '200', name: 'FORM_INPUT_ERROR', msg: 'Invalid input', multiple: [ 
  { msg: 'Invalid Email', props: { input: 'email' } }, 
  { msg: 'Invalid Name', props: { input: 'lastname' } } 
] }

Alternative input error (with input field name, multiple errors) [not my favourite]

errors: [
  { status: '200', name: 'FORM_INPUT_ERROR', msg: 'Invalid Email', props: { input: 'email' } }, 
  { status: '200', name: 'FORM_INPUT_ERROR', msg: 'Invalid Name', props: { input: 'lastname' } } 
]

Again, those are just some initial thought to get a discussion started.

Alternatives considered

No response

Importance

would make my life easier

Additional Information

I thought it's a good idea to bring this up now as the shadow endpints are re-worked anyway

@dummdidumm
Copy link
Member

The first two should be handled by the new error method which you throw. You can pass it a status and a message. The third one would be handled as part of the forms proposal.
I'm not sure some fixed subset of errors is valuable since use cases vary too much. Couldn't you create your own error helpers for reuse in the project?

@dummdidumm dummdidumm added the feature / enhancement New feature or request label Aug 25, 2022
@Rich-Harris Rich-Harris added this to the 1.0 milestone Aug 27, 2022
@Rich-Harris
Copy link
Member

Proposal for more consistent/standardised error handling: #6499

@Rich-Harris
Copy link
Member

#6499 was implemented in #6586, so I'll close this

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

No branches or pull requests

3 participants