Define specific error management standard practices

[EllieKallmier]

Is your feature request related to a problem? Please describe.
Generally good to have a unified approach to error handling, which might fall under the validation umbrella. This to avoid confusion for users (and devs) if errors are raised in inconsistent places, with unclear messages or where e.g. warnings should be logged instead/things could be fixed etc.

A few (low urgency) questions to kick off:

1. Do we want to set up any custom errors for the project?
2. Should we have an error message template/standard for super quick debugging reference?
3. How much should we use try/except/catch statements to manage, vs. just hitting exceptions?

Initial ideas

1. Custom errors allow extra precision with error messaging, and can sometimes be useful for cases specific to the package code. BUT also could just be an extra level of obfuscation that should rather be solved by just adjusting the messages returned with standard errors. I don't have strong opinions on this yet
2. I think having a standard message structure could be useful, if just to save wording decision paralysis on my part when trying to think of the most useful messaging. Even something simple like ensuring a flag for where in the process the error has occurred (e.g : ) feels potentially useful to me.
3. I also don't have strong opinions on this at this stage - I tend to lean toward simplified logic where if it breaks it breaks, but there are definitely cases where that gets annoying.