Re: [go-nuts] What is a ordinary and exceptional error?

[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  
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.
 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c78b000c-bf88-495d-9621-58a4a05c518dn%40googlegroups.com.

Re: [go-nuts] What is a ordinary and exceptional error?

[Kamil Ziemian]

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  
> 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  
 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
>>  
>> 
>> .
>>
>

-- 
You received this message because you are 

Re: [go-nuts] What is a ordinary and exceptional error?

['Axel Wagner' via golang-nuts]

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [go-nuts] What is a ordinary and exceptional error?

[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?

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  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+unsubscr...@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.

Re: [go-nuts] What is a ordinary and exceptional error?

[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

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  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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/870426b7-c3aa-4f64-8594-32b1bbc9525fn%40googlegroups.com.

Re: [go-nuts] What is a ordinary and exceptional error?

[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.

On Fri, Sep 29, 2023 at 2:38 PM Kamil Ziemian  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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD_6J6nEzTpqaZQzTzuDCcxhaUroP%3D%2BLySXqpGT2otOfEQ%40mail.gmail.com.

[go-nuts] 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

-- 
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+unsubscr...@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.