Axel Wagner, you opinin is highly appriciated. niedziela, 1 października 2023 o 15:00:35 UTC+2 Axel Wagner napisał(a):
> 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/87cce8d3-0c64-4f24-8776-4b66d6128764n%40googlegroups.com.
