> errors from GetUser would already say something like GetUser can't know the call site or condition that led to the call and this is often the very thing you

> errors from GetUser would already say something like GetUser can't know the call site or condition that led to the call and this is often the very thing you need. Amending returned errors with useful context is invaluable. Languages that permit this to be done concisely are a blessing: iFailed().expect("and this is why") for example. > Java ... The stack traces are often large and often have poor signal-noise. Earlier this week I needed the whole stack trace. The "who (ultimately) caused that to get called" question gets answered quickly by comprehensive stack traces. I've actually used Java's stack trace behavior for reverse engineering. You can suss the design of some system by throwing something and then reading the stack trace, even when you lack the source code or the time the analyze it all. Good Java programmers know they can structure code specifically to increase the utility of stack traces. > The error handling is very boilerplate and you stop seeing it Wait, weren't we being made to think about it, as one of the supposed benefits? If, as you say, we won't see it then that argument goes out the window.