From 84358bbda6edea083ace67ed0a2da3cf6bef783c Mon Sep 17 00:00:00 2001 From: Klaas van Schelven Date: Fri, 17 Nov 2023 22:55:57 +0100 Subject: [PATCH] Write down thoughts on what the main exception is --- issues/models.py | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/issues/models.py b/issues/models.py index 7c453ee..427c08d 100644 --- a/issues/models.py +++ b/issues/models.py @@ -23,8 +23,20 @@ class Issue(models.Model): def get_main_exception(self): # TODO: refactor (its usages) to a (filled-on-create) field + # Note: first event, last exception + # We call the last exception in the chain the main exception because it's the one you're most likely to care + # about. I'd roughly distinguish 2 cases for reraising: + # + # 1. intentionally rephrasing/retyping exceptions to more clearly express their meaning. In that case you + # certainly care more about the rephrased thing than the original, that's the whole point. + # + # 2. actual "accidents" happening while error-handling. In that case you care about the accident first (bugsink + # is a system to help you think about cases that you didn't properly think about in the first place), + # although you may also care about the root cause. (In fact, sometimes you care more about the root cause, + # but I'd say you'll have to yak-shave your way there). + parsed_data = json.loads(self.events.first().data) exc = parsed_data.get("exception", {"values": []}) values = exc["values"] # required by the json spec, so can be done safely