Errors in Go: From denial to acceptance
The author seems to generalise his use case into a description of how to use panic&#x2F;recover as a bespoke exception mechanism. In that case this is still bargaining.<p>&gt; In imgproxy, I use this approach to stop image processing if the timeout is reached (see here, and here). <i>The goal is not to bother about returning timeout errors from each function</i><p>(emphasis mine)<p>While I understand the pain, I do not like the train of thought. It is our duty as responsible developers to <i>bother</i> with error handling. Luckily this is not a library but a &quot;standalone application&quot;, not a &quot;library&quot;, which is a slightly different use case (e.g negroni has to recover from panics to log and continue serving http requests).<p>The accepted solution looks like† a world of pain waiting to blow up in a myriad of subtle corner cases (do you remember what happens exactly when there&#x27;s a panic in a defer that was called because of a panic, and in which order deferred functions are called?) and is barely more readable. I&#x27;ve seen much more interesting and obviously robust Go 1 patterns (that I can&#x27;t find right now) that e.g pass error handler functions around.<p>† At first sight. Maybe it&#x27;s not when digging deeper, but that&#x27;s not the point: the most glorious thing to me when I read idiomatic Go code is that basically everything is <i>boringly</i> obvious. This is a clever hack and crosses a threshold I&#x27;m not willing to go past in production-class code.