fix: updated pluto.getMessage(id) to throw error and reject the promise instead of fulfill it with a null message

[robertocarvajal]

Description:

Currently, pluto.getMessage(id) will fulfill the promise with a null message instead of failing / throwing error when a message is not found. It's cleaner to properly return an error so we can handle that logic independently.

PS: Just realized my formatter got rid of some unneeded blank spaces across comments.

Checklist:

• My PR follows the contribution guidelines of this project
• My PR is free of third-party dependencies that don't comply with the Allowlist
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I have checked the PR title to follow the conventional commit specification

[curtis-h]

Perhaps this is something to discuss, at the moment Pluto is setup to only throw exceptions when something goes wrong, otherwise it will return a value (T | null).
While we could change to panic when not found, if we do so it should be for every function, ie getLinkSecret, getCredentialMetadata etc

Also I would posit that returning null when not found is more idiomatic and can be handled identically to an exception with less boilerplate, for example:

// current
const msg = await pluto.getMessage(id);
if(msg === null) {
  // handle no message
}
// continue flow

vs

// proposed
try {
  const msg = await pluto.getMessage(id);
  // continue flow  
}
catch(e) {
  // handle no message
}

am I missing something?

[robertocarvajal]

right, both can be handled, it's more about what should be expected in return, my reasoning is similar to what a HTTP call does when something is not found, it returns an explicit error code instead of an OK code with an empty return..

similarly, redux will reject dispatched calls when can't be fulfilled.. it's more about aligning everything with the usual expectations..

[elribonazo]

@robertocarvajal wouldn't u say it makes more sense to throw the exceptions in the redux actions for ex?

In my head, an exception must represent when an action couldn't complete or had an unexpected result. Not having rows doesn't mean that the request didn't complete.

But i agree thats different opinions, you we mind to discuss this in tomorrow's community call?

cc: @mixmix @jeyem

[elribonazo]

OR, we could make it choice of who is writing the code, we could add property to pluto which defines if we throw an exception for non found issues. Then, we also build a standard error message + code that is easy to parse and recognise