<story><title>How to ship production-grade Go</title><url>https://www.oreilly.com/ideas/how-to-ship-production-grade-go</url></story><parent_chain><item><author>tedsuo</author><text>Oh god, there is some terrible advice in that article.&lt;p&gt;1. Don’t wrap errors, log.&lt;p&gt;Errors have two purposes - control flow for your application, and information for the developer and operator. If you are already logging the flow of your program, there is no need to wrap an error and create a call stack - you already have the call stack. If you cannot follow the control flow from your logs, you need to improve your logging, because you will also need to debug production problems that do not produce a literal error object.&lt;p&gt;And if you want more causality than you can get out of your logging, consider upgrading from logging to tracing. I contribute to &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;opentracing.io&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;opentracing.io&lt;/a&gt; so naturally that’s the tracing API I would suggest you look at.&lt;p&gt;2. Do not do anything with panics except recover from them or exit.&lt;p&gt;If you have a panic that you cannot recover from (and in general, that should be all of them), then it means your application is in a unknowable state. While Go is not as unsafe as C, any and all state in your program could be bad, and it is completely unclear what is still working and what is not. Nothing you do at this point is safe. For the love of god, do not hang your application and prevent it from exiting by trying to send a Slack message.  Your goal should be to restart your program from a fresh clean state as quickly as possible, not to tie it up on the way out. Let the program exit and have an external monitoring program, whose state is NOT corrupted because its in a separate process, do all of the triage and reporting.</text></item></parent_chain><comment><author>paulddraper</author><text>(1) I see this all the time.&lt;p&gt;An error is logged and propogated, then logged and propogated, then logged and propogated, then pretty soon your logs are 50x copies of themselves and the flood of logging sweeps you away.&lt;p&gt;You either (a) know what you to do about an error and log it or (b) you don&amp;#x27;t know what to do and propogate it.&lt;p&gt;An error should be logged eventually, but it shouldn&amp;#x27;t be logged 20 times.</text></comment>
<story><title>How to ship production-grade Go</title><url>https://www.oreilly.com/ideas/how-to-ship-production-grade-go</url></story><parent_chain><item><author>tedsuo</author><text>Oh god, there is some terrible advice in that article.&lt;p&gt;1. Don’t wrap errors, log.&lt;p&gt;Errors have two purposes - control flow for your application, and information for the developer and operator. If you are already logging the flow of your program, there is no need to wrap an error and create a call stack - you already have the call stack. If you cannot follow the control flow from your logs, you need to improve your logging, because you will also need to debug production problems that do not produce a literal error object.&lt;p&gt;And if you want more causality than you can get out of your logging, consider upgrading from logging to tracing. I contribute to &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;opentracing.io&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;opentracing.io&lt;/a&gt; so naturally that’s the tracing API I would suggest you look at.&lt;p&gt;2. Do not do anything with panics except recover from them or exit.&lt;p&gt;If you have a panic that you cannot recover from (and in general, that should be all of them), then it means your application is in a unknowable state. While Go is not as unsafe as C, any and all state in your program could be bad, and it is completely unclear what is still working and what is not. Nothing you do at this point is safe. For the love of god, do not hang your application and prevent it from exiting by trying to send a Slack message.  Your goal should be to restart your program from a fresh clean state as quickly as possible, not to tie it up on the way out. Let the program exit and have an external monitoring program, whose state is NOT corrupted because its in a separate process, do all of the triage and reporting.</text></item></parent_chain><comment><author>bigdubs</author><text>(1) is entirely debatable. imho your prescription is bad advice. it is very helpful to have []uint call stack pointers (i.e. not a ton of data) associated with errors for the 1 in 10 chance you&amp;#x27;ll need that information, especially when dealing with libraries you don&amp;#x27;t control that generate errors (which for most programs is the majority, things like lib&amp;#x2F;pq etc.)</text></comment>