The point is that "simply returning an error message" is fine when you know that it actually contains the relevant reason. You don't need to blindly annotate t

The point is that "simply returning an error message" is fine when you know that it actually contains the relevant reason. You don't need to blindly annotate the reason for an error every single place an error gets returned. You often end up with redundant errors like this: > could not load document "doc.txt": error reading document "doc.txt": could not open "doc.txt": open "doc.txt": file not found So, sometimes you just return an error upwards, sometimes you conditionally wrap it depending on where the error came from, sometimes you conditionally wrap it depending on what the error type is. And yes, you may be working with poorly-written code that doesn't do this, or you may be working with poorly-written code that just returns some fmt.Errorf() for everything... are you going to parse that? (My approach would be to fix the dependency so it returns better errors, if its needed for good error handling on my end.) Poorly written code is a hazard in all languages--I could just as easily throw RuntimeException in Java if I didn't care how it was handled. > While Java stack traces may be verbose, with even an ounce of experience one will realize that you only have to look at the top message and the “caused by” top messages. I can only conclude from this statement that I don't "even have an ounce of experience" with Java. That's extremely harsh! Maybe I'm just a complete idiot and it's hopeless, I should quit my job, or maybe I just haven't put in enough years working with Java. My first complaint is that the context for an error is not present in the stack trace, because the stack trace only contains the location of the error, and does not tell you which objects the error is associated with (like, which user ID, just to make up an example). That information is either encoded in the exception message (it often isn't) or it is in the log somewhere, although you may not have an easy time finding the relevant line in the logs. My second complaint is that the top and the bottom of the Java stack trace are usually not what you care about. You care about something near the top (but not at the top), some method which called a method that threw the exception, and you care about something farther down near the middle or bottom which shows the operation the program was doing (but not all the way at the bottom, because that will often just be some generic top-level try/catch).