3 ms·
Context is quite important, I agree. However, when possible, giving _actionable_ info can really help, especially if the user can see that error. For example,
by jiehong 6y ago
Context is quite important, I agree.
However, when possible, giving _actionable_ info can really help, especially if the user can see that error.
For example, you can try to explain why this file is expected, and give a link to the spec/doc.
Extremely helpful when called at 4am in production.
Alternatively, I've seen some experiments with extreme reproducibility: capture the full context (network requests, filesystem, db state, etc.), and spin up an instance with that state. This way devs can deterministically reproduce the issue, and fix it. But, it supposes that the application is written to support this fairly well (by either being very functional, or by having probes in all non-pure functions).
- q3k 6y agoYou can't always have actionable context, because generally if you could, you wouldn't throw the error in the first place. :) I mean, apart from the obvious 'database connection failed, check that it's up'. Troubleshooting hints should live in production runbooks, which tell you, for any firing alert, what is it that might cause it, how to investigate further, where the code lives, etc.