front: Have a standard way to type catch blocks in type script

[anisometropie]

Description and goal

different ways have been used throughout the app to handle catch block. We need to have a reliable, unified standard to handle them.

catch (e: unknow)

Anything can be thrown, a string, an object, an Error, so the default type for e is unknown and we have to test explicitly what we’re dealing with.

(catch (e: any) is no longer recommended)

catch (e: unknown) {
    if (e instanceof Error) {
      console.error('Network or JSON parsing error:', e.message);
    } else if (typeof e === 'string') {
      console.error('String error:', e);
    } else {
      console.error('Unknown error:', e);
    }
  }

Acceptance criteria

• Have all the catch blocks in the app using a defined pattern (for example the same function) with different errors handled
• do not lose the original information.

  .catch((e) => {
        console.error(e);
        dispatch(
          setFailure({
            name: t('errorMessages.error'),
            message: t('errorMessages.unableToDuplicateATrain'),
          })
        );
      });

here the error will only appear in the console, and then will be lost.

We can have something like this to keep the original error in the store for later review.

.catch((e) => {
          console.error(e);
          dispatch(
            setFailure({
              name: t('errorMessages.error'),
              message: t('errorMessages.unableToDuplicateATrain'),
              originalError: e
            })
          );
        });

[sim51]

I did that when managing the errors from editoast. For example, you can take a look at https://github.com/osrd-project/osrd/blob/689d6c36ef33a1e5d96ad428473b84aba010318e/front/src/common/Pathfinding/TypeAndPath.tsx#L134-L136

In src/utils/errors, you find function that handle error's message (and name) by given an unknown object. Those function do their best to create a message (and do the translation).

BTW, loosing the error at a specific level in the app is normal, it means that the error is well handle by the application.

IMHO, we can close this ticket