Agree. Dave Cheney is a true treasure of Go community. He from time to time write code in wrong way, but I can't blame anyone of that, too much sins are on my side.
Haha, thanks. I've been using this Chrono Trigger avatar for 6 years. In all that time, you're the first person to mention anything about it! I'm glad somebody else out there recognized it.
Definitely informative, thanks for sharing. However, at least to me I would argue errors are more of a message, and it feels weird to correspond message strongly with behaviors (e.g. a word doesn't always need to have a behavior). Even in the example of the presentation, I think checking if a message is temporary or not is more of a type or status check than about behaviors.
The whole reason why Go doesn't have the try catch syntax and intentionally use this pattern is to make it obvious which function may "throw" an error. With a try catch, it's not obvious to you which function/method throws an error and interrupts the execution flow. There's a nice blog that explains about this in the Go website. I personally prefer this approach to the try catch.
Try/catch is a crutch. Coming from Python, every time I find myself saying, "I wish I could just try-catch right now" it's a smell that my control flow isn't optimal. It breaks the Sequential part of Communicating Sequential Processes. Try/catch is GOTO with a bow tie and top hat.
I'm sorry but this isn't a very good pattern, or somewhat antiquated with regard to older languages. Just as with concerns of monitoring and logging, error handling can too be subjective. A developer shouldn't be tasked with classifying an error, let alone determine which mechanism to use in conveyance.
this should be part of standard library
Agree. Dave Cheney is a true treasure of Go community. He from time to time write code in wrong way, but I can't blame anyone of that, too much sins are on my side.
Very good pacing on this presentation. I was able to follow along and really absorb what he was saying.
Haha, thanks. I've been using this Chrono Trigger avatar for 6 years. In all that time, you're the first person to mention anything about it! I'm glad somebody else out there recognized it.
Now your profile picture is nine years old, isn't it? 👀
5:25 I think there is a typo and in if it should be "err.Error()". Otherwise, great talk.
a frog in well is Chinese prob.
nice talk 👍
Very practical. Where did you put your library?
github.com/pkg/errors
F*ck yeah, thats what Ive been looking for :D
Definitely informative, thanks for sharing. However, at least to me I would argue errors are more of a message, and it feels weird to correspond message strongly with behaviors (e.g. a word doesn't always need to have a behavior). Even in the example of the presentation, I think checking if a message is temporary or not is more of a type or status check than about behaviors.
how else would you communicate that a network error occured?
This starts to remind me of Exceptions, but done manually instead of automatically.
Exceptions are implicit, this is explicit. Very far from the same.
github.com/colindev/x/tree/master/errors
this demo is study follow this video
but i am not sure it's correctly
github.com/pkg/errors
I played it at 1.25x just so i do not get bored with slow pace
1.5 was even better
He is chewing it so sloooooooowly
guys, just add try catch into Go
The whole reason why Go doesn't have the try catch syntax and intentionally use this pattern is to make it obvious which function may "throw" an error. With a try catch, it's not obvious to you which function/method throws an error and interrupts the execution flow. There's a nice blog that explains about this in the Go website. I personally prefer this approach to the try catch.
Try/catch is a crutch. Coming from Python, every time I find myself saying, "I wish I could just try-catch right now" it's a smell that my control flow isn't optimal. It breaks the Sequential part of Communicating Sequential Processes.
Try/catch is GOTO with a bow tie and top hat.
I'm sorry but this isn't a very good pattern, or somewhat antiquated with regard to older languages. Just as with concerns of monitoring and logging, error handling can too be subjective. A developer shouldn't be tasked with classifying an error, let alone determine which mechanism to use in conveyance.
If a developer doesn't classify the error who will? Will the machine just spit a hexdump and it's your problem?