r3code

{
    "basics": {
        "name": "Dmitriy S. Sinyavskiy",
        "label": "Go Developer | Site Reliability Engineer",
        "image": "https://avatars0.githubusercontent.com/u/1355056?v=4",
        "url": "https://habr.com/ru/users/r3code/",
        "summary": "I'm a software developer with more than 17 years of experience. I try to do my best and encourage teammates to do the same.  \n\nI prefer to create documented, well organized and tested code. Other developer should have an ability to start working with the code without any need to ask me about it.\n\nMy open-source code here at GitHub: https://github.com/r3code\n\nOther hobbies:\n* teach kids computer science and programming\n* ship-modeling from plastic\n* snowboarding\n\nI like to work with people. I can understand what stakeholder really need and translate the data to the developers language. Before tell, I listen then propose. For me, it is very important to do the work! I use Kanban board to manage task flow and EventStorming methodology to und

StevenACoffman

This is my notes from a few articles:

• Golang Error Handling Best Practices
• Error Handling in Go

Some error values are mostly just used for control flow. For example, "Access Denied", or "Authentication Required".

In my opinion, you should only add stack trace to an error which is potentially going to break your program. A logical error like we have seen in the authorization example does not need a track state. But since Wrap method can be used to ammend original error message which is also called as annotating an error, the choice is up to you.

The types of errors that would bubble up to be a 500 Internal Server Error generally require investigation by a developer. In these cases, a stacktrace (and ideally other contextual information) is incredibly valuable.