On Sun, Oct 1, 2023 at 2:37 PM Jerry Londergaard <[email protected]> wrote:
> I've been thinking about this point as well lately. I think I understand > (at least some of) the conditions under which > you would call a panic(), but I still don't quite grok why it's better > than returning an error if that error is properly > handled. If I panic(), then no defer() statements will be called, and I > don't give any chance to the calling code to cleanup etc. > `panic` does call defered functions. The reason why not to return an error is who is responsible for fixing the failure condition. An error is usually returned to the user/operator and it is expected that they remedy it. For example, if a connection fails because a name can not be resolved, the program should just print "can't resolve example.com", signalling that the user has to fix their inputs or network setup. On the other hand, a panic is expected to be reported to the developer for fixing. If a program has a bug, there really is nothing the user can do. No amount of changed inputs or re-running will make the bug go away - the code needs to be fixed. Hence, a panic contains a stack trace (the developer needs that stack trace to effectively find and fix the bug), while an error does not (the user does not know your code so the stack trace doesn't help them). To be clear, not everyone follows this philosophy and not every program follows this dichotomy (in a service, the role of operator and developer often overlap - hence "devops"). But it's a pretty self-consistent view that can answer a lot of questions about good error handling and messages. > > I struggle to think of a scenario where it would be better to *not* allow > the code to cleanup and exit gracefully. Is it because we > don't want to give the code the possiiblity of ignoring the error? > > On Saturday, 30 September 2023 at 9:10:09 pm UTC+10 Kamil Ziemian wrote: > >> Thank you mister Rader, this was what I needed. I think I now have >> intuition what this text want to say. >> >> Best regards >> Kamil >> >> piątek, 29 września 2023 o 23:58:39 UTC+2 Kurtis Rader napisał(a): >> >>> An ordinary error is one that can be expected to occur. For example, >>> opening a file may fail because the file does not exist or the process >>> doesn't have permission to open it. An exceptional error is one that is not >>> expected to occur and often indicates the state of the program is invalid. >>> For example, a data structure that contains pointers that should never be >>> nil. If a nil pointer is found that means the structure is corrupted. >>> Probably due to a programming bug. Exceptional errors are those which may >>> make it unsafe to continue execution. In which case calling panic() may be >>> the only sensible course of action. >>> >>> On Fri, Sep 29, 2023 at 2:38 PM Kamil Ziemian <[email protected]> >>> wrote: >>> >>>> Hello, >>>> >>>> In Go FAQ we read "We believe that coupling exceptions to a control >>>> structure, as in the try-catch-finally idiom, results in convoluted >>>> code. It also tends to encourage programmers to label too many ordinary >>>> errors, such as failing to open a file, as exceptional.", " Go also has a >>>> couple of built-in functions to signal and recover from truly exceptional >>>> conditions.". >>>> >>>> Can you explain to me in general terms what is a ordinary and >>>> exceptional error? I'm just a hobbist programer and I never think about >>>> errors in that way. >>>> >>>> Best regards, >>>> Kamil >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/e9fdeb9d-e3b6-49ea-b7e3-5ab7ddafea7bn%40googlegroups.com >>>> <https://groups.google.com/d/msgid/golang-nuts/e9fdeb9d-e3b6-49ea-b7e3-5ab7ddafea7bn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> Kurtis Rader >>> Caretaker of the exceptional canines Junior and Hank >>> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7a17fcf5-480b-44c8-89b4-2a44b1f71c2en%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/7a17fcf5-480b-44c8-89b4-2a44b1f71c2en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG2ZGY3FUwieXekJDaK_qh_Dacf-zQxG5TPnE8k1sXxVQ%40mail.gmail.com.
