What is a ordinary and exceptional error?

[Kamil Ziemian]

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

[Kurtis Rader]

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.

--
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 golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e9fdeb9d-e3b6-49ea-b7e3-5ab7ddafea7bn%40googlegroups.com.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Kamil Ziemian]

Thank you mister Rader, this was what I needed. I think I now have intuition what this text want to say.

Best regards

Kamil

[Jerry Londergaard]

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. 

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?

[Axel Wagner]

On Sun, Oct 1, 2023 at 2:37 PM Jerry Londergaard <jlonde...@gmail.com> 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 <kziem...@gmail.com> 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 golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e9fdeb9d-e3b6-49ea-b7e3-5ab7ddafea7bn%40googlegroups.com.

--

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 golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7a17fcf5-480b-44c8-89b4-2a44b1f71c2en%40googlegroups.com.

[Kamil Ziemian]

Axel Wagner, you opinin is highly appriciated.

[Jerry Londergaard]

On Monday, 2 October 2023 at 12:00:35 am UTC+11 Axel Wagner wrote:

On Sun, Oct 1, 2023 at 2:37 PM Jerry Londergaard <jlonde...@gmail.com> 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.

You're right, I wonder how I came to this completely wrong conclusion??

Anyway, thanks for your insights, they are much appreciated.