Vue3/State management/Components: Unnecessary Try/Catch

Question

I hope there is a general consensus to this question and I'm not asking for people's opinions.

My component dispatches a action method:

await dispatch('someAction', payload)

Store

async someAction({commit}, payload){
  try {
    const data = await http.get('/foobar', payload)
    commit('someCommit', data.data)
  } catch (error) {
    throw error
  }
}

In the store method, the try/catch is throwing an Eslint error unnecessary try/catch , which to me doesn't make sense. The server can throw an error and the http call can fail, so in order to avoid the commit from firing I added a try/catch block. I guess I could add a if (data) commit(... but isn't it cleaner with a try/catch?

Also, in the catch I'm throwing the error so that the original dispatch call can be stopped (if it was in its own try/catch).

Am I doing things wrong here? Is there a 'better' way of doing things?

Answer 1

From the docs

A catch clause that only rethrows the original error is redundant, and has no effect on the runtime behavior of the program. These redundant clauses can be a source of confusion and code bloat, so it's better to disallow these unnecessary catch clauses.

The preferred way to handle an error is to... well, handle it. Log it, respond to it in some way, just don't throw it. However, as the docs also say,

If you don't want to be notified about unnecessary catch clauses, you can safely disable this rule.

Which can be done in your eslint config:

"rules": {
  "no-useless-catch": "off" // "off" or 0 both work
}

Answer 2

** Try catch will instantly hault that stack and fire the catch... You can put any type of callback in there... Like for instance you can recursively function again to retry...

Also you dont have to worry about dispatches and stuff like that in pinia just use this inside the action as if it were a normal javascript class.

state =( (){
 color = "red"
},
actions{
  changeColors{
    try{
      const colors = await api.getColors()
      this.colors = colors.data // this doesnt fire if the request fails 
  }
 catch(error){
    // were only here because of the fact that the runtime 
    // threw an error... If we dont catch it nodejs crashes...

    // now you do anything you want here -> -> -> but just know the code 
    // above did not complete... so thats what you do here.

    console.log(error)
    anyFunction(error)
}
  },
})

When you catch an error... You are CATCHING an error that was thrown inside the try block... So to go around in circles and then rethrow it... Is a waste of memory its like console logging a console log...

This is why AI generated code is useless(just guessing you generated this off of something... Not saying it in a negative way.. u obv know what code is, but you wouldnt of used throw there, you would of used something like console.log(error.message or whatever else you care about. Or used some type of middleware to forward it back to the user.

). When you dont throw an error it causes the runtime to terminate. When you catch the error... You are trying to prevent that from happening by turning it into an event listener esentially... When an error is thrown do this... To turn around and throw it... is a waste of resourses especially if u are using that type of design pattern on something like react where or vue where your doing the same thing hundreds of times in little variated ways.