Update/type errors

[ccali11]

Shane - @DemogorGod and I are meeting on Thursday to do the integration work. If I don't have a good pattern already, I think the necessary and appropriate error handling required will become very apparent then. For now, I tried to follow a few principles, which were essentially to:

• Wrap mostly everything in a try catch
• Propagate errors as much as possible
• Throw errors so that we can handle them globally (if/when we decide to handle them this way; but for now, the errors simply propagate from where they happen to the console triggered by the UI element)
• Created interface(s) that were consistent (e.g., ApiResponse)
• Removed return statements when a return hasn't been explicitly required by UI
• Implemented all this for the UI/UX that is most critical. As we connect UI with composables, I'll apply whatever I learn from this PR to those methods as well.

Looking forward to feedback. Ping me if anything is confusing and we can talk through anything that is unclear or not best practice in your eyes.

[shanejearley]

@ccali11 Type changes look good. Error handling could be improved by using built-in Express functionality: see here. Looks like some spots do require custom errors (a user is not found and the returned rows are empty, we throw a user not found and handle accordingly in the app side with a try catch). Don't think we need to both return custom errors sometimes in json response and sometimes throw. Probably just return valid or undefined data or throw.

[ccali11]

@ccali11 Type changes look good. Error handling could be improved by using built-in Express functionality: see here. Looks like some spots do require custom errors (a user is not found and the returned rows are empty, we throw a user not found and handle accordingly in the app side with a try catch). Don't think we need to both return custom errors sometimes in json response and sometimes throw. Probably just return valid or undefined data or throw.

Ok so basically remove try catches from express routes and replace with error handling middleware?

[ccali11]

@shanejearley - So put another way (and to use an example), are you suggesting you prefer the first option to the second?

router.post('/nonce', async (req: express.Request, res: express.Response, next: express.NextFunction) => {
  try {
    const { address } = req.body
    const nonce = await upsertNonce(address)
    if (nonce) {
      res.setHeader('Content-Type', 'text/plain')
      res.status(200).json({
        error: false,
        message: 'Nonce retrieved',
        data: nonce
      })
    }
  } catch (error: any) {
    next(error)
  }
})

router.post('/nonce', async (req: express.Request, res: express.Response, next: express.NextFunction) => {
  try {
    const { address } = req.body;
    const nonce = await upsertNonce(address);
    if (nonce) {
      res.setHeader('Content-Type', 'text/plain');
      res.status(200).send(nonce);
    } else {
      res.status(404).json({
        error: true,
        message: 'Error getting nonce'
      });
    }
  } catch (error: any) {
    next(error);
  }
});

[shanejearley]

I like the first example for route handlers, since upsertNonce can propogate the provided error message (right now it's throwing a predetermined message, for which maybe there's a good argument), so that it is caught in the try block. Do you have a strong preference?

For that example, do we want to have upsertNonce (and any other DB messages) throw specific error codes (say a 404 if the DB is down) or messages (say 'Not found'). This might be out of scope for this PR but maybe worth working towards.

To get to launch quicker.

[DemogorGod]

Love it!, Will work to incorporate as much as i can to the front-end!