Discussion: exception and error handling policy

I'm creating this issue to kick off the discussion around exception handling policy. The goal would be to have a guideline which would help us get a consistent approach across the codebase.

This style guide is a good starting point, but I think there is room for improvement. This guide has lots of useful information, especially regarding security, but it does not contain a specific coding discipline which we can follow and verify when reviewing MRs.

Support-wise, we would like to:

  1. Ensure we never suppress/ignore an exception, whenever there is an exception, we should find it in the log file
  2. Try to write meaningful exception messages, exceptions that have no messages should look suspicious
  3. Try to identify the specific resource which is related to the exception - this allows for easier troubleshooting

I would also like to discuss concerns around exceptions, from the top of my head I can mention that writing exceptions to the log can spark worries about security and privacy. For that, I'd like to propose the following for consideration:

  1. Ensure exception messages do not have sensitive information,
  2. It is better to consider the point above when writing exception messages than when handling them
  3. Ensure exception messages never reach the UI, this would free developers from that concern when writing messages

Finally, I usually think that bubbling exceptions up is a good idea. For instance, this would cause sentry to notify that it ocurred, letting us know of something that might be off with our code or our environment.

As I mentioned, this is just to get things started. Would love to hear more about other opinions.

Edited by Lee Matos