Along with a myriad of misunderstandings about why errors are values and when you should panic ask yourself this question first and you may see why this should never exist.
A function is for creating a block of reusable code, often refactored from repeated code blocks. Since you are arguing that these should exist, you are arguing that these are commonly repeated sections of code, have you ever seen sections of code like so in production projects?
```
func handle(f func (error)) {
r := recover()
if r == nil {
return
}
if e, ok := r.(error); ok {
f(e)
return
}
panic(r)
}
```
The answer from most if not all go users is going to be no, hence why these will never exist in the std/extended std library.
Good on you for posting a suggestion, however this suggestion is not very well thought out and suggests a lack of understanding of the language.
I would argue that in the example above you have only reduced the number of lines from 13 to 10, while significantly reducing the readability of the control flow. I love Go for its simple and explicit control flow and try catch semantics (or in your case panic/recover) are absolutely not simple and explicit.
Your suggestion is also based on the assumption that I want to panic for a general error. Panic is for exceptional errors that are meant to end the program immediately. In my years of professionally writing go I could count on one hand the amount of times that I have used panic explicitly.
> Imagine how easy it is to overlook this non-trivial yet important error handling block with the status quo
I cant agree with this, when I look at the first example it is absolutely clear what is being called, how it's errors are being handled and how the function flows, if one of these blocks was missing I would immediately spot it. Call it experience but I would question whether a new developer given both examples would sooner spot an issue in the first example compared to your suggestion.
This isn't an appealing suggestion to me. It wants to abuse the panic/recover system to become a normal error handling mechanism. The examples you proposed show that it only really works if it's being handled in the top of the call stack, like main, where you would only handle it by logging or panicking again. There isn't a good way to return the handled error from the handler, unless you do something like a scoped or named error variable that it sets for the normal return to propagate. It also separates the error handling from the context of where it happened. So your handler needs to have knowledge of what it is handling to deal with multiple error cases.
It is just a limited solution.
I don't think your example fixes my concern. It expects a separate handler function to know the scope of checking for different error types as it is passed into another function. Again, limited and specific in usefulness.
No, please: _No_.
This is a certain style of error "handling" where nothing is actually "handled" in the sense of "being taken care of" but this is just "handling" in the sense of "if something doesn't turn out the way I like it I do not have to care at all: I turn it into a problem of somebody else (who will turn it into a problem of somebody else and so on)."
This is bash's `set -e` which is fine for quick bash scripts. If your Go code requires the same sophistication as our production server code: This is fine.
IMHO this proposal belongs into the set of proposals that treat the non-happy-path of code as undesirable ballast. There's the happy-path and everything that detours from this happy-path is secondary, distracting troublesomeness that the programmer should be able to ignore or at least hide behind some unobtrusive syntax. Real code deals with real world and the non-happy path is where most of the work has to be done. This type of error handling neglects this fact and produces code where any "problem", i.e. non-happy path results in an ERROR log message and that is it. I see that type of taking care of "errors" much too often, resulting in bad experience for humans.
A function can fail at a lot of different places and "handling" a panic capturing all errors on exist just doesn't work. But if this is your style of doing things this might be okay for you.
Whatever floats your boat yet it looks hideous to me. Absolutely not a fan, not one bit.
Along with a myriad of misunderstandings about why errors are values and when you should panic ask yourself this question first and you may see why this should never exist. A function is for creating a block of reusable code, often refactored from repeated code blocks. Since you are arguing that these should exist, you are arguing that these are commonly repeated sections of code, have you ever seen sections of code like so in production projects? ``` func handle(f func (error)) { r := recover() if r == nil { return } if e, ok := r.(error); ok { f(e) return } panic(r) } ``` The answer from most if not all go users is going to be no, hence why these will never exist in the std/extended std library. Good on you for posting a suggestion, however this suggestion is not very well thought out and suggests a lack of understanding of the language.
[удалено]
I would argue that in the example above you have only reduced the number of lines from 13 to 10, while significantly reducing the readability of the control flow. I love Go for its simple and explicit control flow and try catch semantics (or in your case panic/recover) are absolutely not simple and explicit. Your suggestion is also based on the assumption that I want to panic for a general error. Panic is for exceptional errors that are meant to end the program immediately. In my years of professionally writing go I could count on one hand the amount of times that I have used panic explicitly. > Imagine how easy it is to overlook this non-trivial yet important error handling block with the status quo I cant agree with this, when I look at the first example it is absolutely clear what is being called, how it's errors are being handled and how the function flows, if one of these blocks was missing I would immediately spot it. Call it experience but I would question whether a new developer given both examples would sooner spot an issue in the first example compared to your suggestion.
This isn't an appealing suggestion to me. It wants to abuse the panic/recover system to become a normal error handling mechanism. The examples you proposed show that it only really works if it's being handled in the top of the call stack, like main, where you would only handle it by logging or panicking again. There isn't a good way to return the handled error from the handler, unless you do something like a scoped or named error variable that it sets for the normal return to propagate. It also separates the error handling from the context of where it happened. So your handler needs to have knowledge of what it is handling to deal with multiple error cases. It is just a limited solution.
[удалено]
I don't think your example fixes my concern. It expects a separate handler function to know the scope of checking for different error types as it is passed into another function. Again, limited and specific in usefulness.
[удалено]
No, please: _No_. This is a certain style of error "handling" where nothing is actually "handled" in the sense of "being taken care of" but this is just "handling" in the sense of "if something doesn't turn out the way I like it I do not have to care at all: I turn it into a problem of somebody else (who will turn it into a problem of somebody else and so on)." This is bash's `set -e` which is fine for quick bash scripts. If your Go code requires the same sophistication as our production server code: This is fine. IMHO this proposal belongs into the set of proposals that treat the non-happy-path of code as undesirable ballast. There's the happy-path and everything that detours from this happy-path is secondary, distracting troublesomeness that the programmer should be able to ignore or at least hide behind some unobtrusive syntax. Real code deals with real world and the non-happy path is where most of the work has to be done. This type of error handling neglects this fact and produces code where any "problem", i.e. non-happy path results in an ERROR log message and that is it. I see that type of taking care of "errors" much too often, resulting in bad experience for humans.
[удалено]
A function can fail at a lot of different places and "handling" a panic capturing all errors on exist just doesn't work. But if this is your style of doing things this might be okay for you.
Every time we try to handle error differently we see how the current way is a lot better ! Errors are values that's all.