[marwatk]

The bigger issue is that returning the error without wrapping provides zero context and after a crash you're stuck trying to figure out which of a hundred calls to Write was responsible for "write error" or some other equally ambiguous message that's nearly impossible to track down.

So you have to resort to a poor man's stack trace: if err != nil { return fmt.Errorf("my thing: %w", err) }

(We use wrapcheck via golangci-lint to enforce it because not having context for an error has bitten us so many times)

[Gibbon1]

Things I tend to do in my firmware for errors.

Record the error line number where the error happened. Use __builtin_return_address(0) to fink on the caller.

Idle thoughts. Despite it's provenience BASIC's on error goto has merit. The problem with try/catch is creating scoped blocks of code that's annoying.

   try
   {
     // scoped stuff
   }
   catch
   {
   }

vs

   on_error_goto label;

   // stuff

   label:

Also a thought is having a separate error_return keyword. And the ability to mark functions with 'no error'

[metaltyphoon]

The thing with try/catch is that many times, code that throws doesn't have to be handled on the call site! So you can easily have a happy path and kick the bucket to a location where the error can ACTUALLY be handled property.