Skip to content

Improve error handling #9404

Open
Open
@ShGKme

Description

How to use GitHub

  • Please use the 👍 reaction to show that you are interested into the same feature.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

1. Do not use console.debug for errors, use console.error if necessary

We also use console.info and console.warn sometimes. Shouldn't we use console.debug only for debugging related stuff?

Why: Errors should be logged as errors, they have a separate place in the dev tools and display

Examples:

try {
  await foo()
} catch (error) {
  // ❌
  console.debug(error)
  // ✅
  console.error(error)
}

2. Do not catch an exception, if it is not required

Catch an exception in case:

  1. You need special processing
  2. An exception here may break something

Why: a caught exception is "missed" from further processing

Examples:

try {
  await foo()
} catch(error) {
  // ❌ Catch just in case
  console.error(error)
}

try {
  await foo()
} catch(error) {
  // ✅ Some special processing, for example
  // ...showing a toast
  showError(error.message)
  // ...work with the exception
  if (error.responsestatusCode === 404) {
    // Special case
  }
}

// 📁 someStore.js
const actions = {
  someAction({ commit }) {
    try {
      commit('FOO')
      await foo()
    } catch(error) {
      // ✅ Need to revert changes
      commit('REVERT_FOO')
      }
    }
  }
}

// 📁 Component.vue
export default {
  async created() {
    try {
      await foo()
    } catch(error) {
      // ✅ The component mounting will be failed without catching the error
      // Some processing
    }
  },
}

3. Don't forget to re-throw an exception if it may not be processed

Why: Otherwise it is missed

Example:

try {
  await foo()
} catch(error) {
  if (error.responsestatusCode === 418) {
    // ...Custom processing...
  } else {
    // ✅
    // What if the error is not 418 ?
    throw error
  }
}

4. Think about possible exceptions and errors

try {
  await foo()
} catch(error) {
  // What may go wrong in `foo`?
  // Only general unexpected exceptions? Or also some domain-level errors?
  // May there be special results of `foo` that we need to proceed implicitly?
}

5. General errors

In case an error required special processing (for example, displaying a special message) and it is some specific action error, some general app-wide error - add general catching.

For example:

  • axios interception
  • Top-level window.addEventListener('error') or app level catch
  • Top-level window.addEventListener('unhandledPromiseRejection') or app level catch

See also

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions