feat: Use custom exceptions for recording errors. #193
Conversation
In the past, we used generic exceptions to record errors to New Relic. This creates custom exceptions for producing and consuming so that we can query New Relic on custom exceptions instead of relying on log messages. edx/edx-arch-experiments#389
| raise Exception(error) | ||
| except BaseException: | ||
| raise EventConsumptionException(error) | ||
| except EventConsumptionException: | ||
| self._add_message_monitoring(run_context=run_context, message=maybe_kafka_message, error=error) | ||
| record_exception() |
There was a problem hiding this comment.
So will this end up recording the EventConsumptionException, or will it record the type of error?
There was a problem hiding this comment.
(Well, I guess if we lose the type of error, that's already happening, so no complaint here.)
There was a problem hiding this comment.
Yeah, we were losing the type of error previously. This allows us to at least see a EventConsumptionException recorded as the error.class in New Relic.
| @@ -38,6 +38,10 @@ | |||
| confluent_kafka = None | |||
|
|
|||
|
|
|||
| class EventProductionException(Exception): | |||
There was a problem hiding this comment.
Should these live in a public module?
There was a problem hiding this comment.
I don't think it needs to, since this is custom to the producing code, and we already had the pattern of keeping consumer exceptions in the consumer.py file. I am open to disagreements, though.
In the past, we used generic exceptions to record errors to New Relic. This creates custom exceptions for producing and consuming so that we can query New Relic on custom exceptions instead of relying on log messages.
edx/edx-arch-experiments#389
Merge checklist:
Check off if complete or not applicable: