Out of interest, how about the proposed check and handle changes proprosed for v2? Details here: https://dev.to/deanveloper/go-2-draft-error-handling-3loo
Still not a fan. These seem like schemes for people who are annoyed by errors, and just throw them over the wall... similar to say putting an entire python block in a try/except. With any sufficiently large application you start to realize how awful that is, especially when something fails and the only log is 'EOF'. I've learned to treat errors as first class citizens, because they are. I always add an annotation and…
So much this: "it does make me think about whether this function call can error, and what I should do about it if it does." This thinking is why C programs are the most reliable computing substrate - because errors can happen and there is no substitute for the programming taking a moment to think the possibilities of error. Build that thinking into the dev process, and you have a hope of reliability within the proces…
Yeah, they are so reliable. A living proof of good quality. https://www.cvedetails.com/vulnerability-list/opmemc-1/memor...
Linux hasn't segfaulted on me in years. Nor has Python C level (except when I use ctypes to use openssl directly). Nor has gcc, emacs or any of the standard shell commands I use. When I worked in a large C shop writing network servers, we all got emailed whenever our code segfaulted with a stack trace. Now our Java servers routinely catch all exceptions and then need to be restarted for some reason when the network glitches. I wouldn't use C for high velocity business logic ("alternating soft and hard layers") but I'd absolutely use it for stuff that needs reliability. I'd use Go now also.
Same. I don't like how this requires you to use named parameters and defer to add context to errors. It's way too easy to shadow err and I can see this causing a lot of pain in the future.
Even with checked exceptions, you have to be careful. You may not want exceptions from every function you call to fly up to the caller. function X() throws Oops { okToFail(); // fine if this failure goes up unexpectedFailure(); // not fine to go up } Unfortunately, once you tell the compiler its ok for exeptions to go up, that rule applies to the whole function.
It’s contrary to Go core values of simplicity and avoiding slow patterns (using defer statements for error handling). It seems like a net loss and I would expect the proposal to be rejected.
I am strongly against this. `try` seems exactly like a function yet it is not acting like a function at all. People wouldn't expecting calling a function may return from the caller. And there is a reason why golang doesn't have macros. With macros all kind of craziness would be possible, and would really difficult to read different kind of projects' code.
> People wouldn't expecting calling a function may return from the caller.
Why? This is essentially the same as the reset/shift pattern in e.g. Scheme - when you call shift from within a reset call, that might cause you to return directly from that. And that is a rather well-behaved pattern which composes quite well, it's nothing like the inherent weirdness of, e.g. call/cc.
Please for the love of god no. Go is awesome for its simplicity. Errors should not be abstracted out of handling convenience. Errors are just values either eliminate the need for the error or handle it like you would any other value. Stop trying to make go work like every other language.
This isn’t a replacement for go error handling, it’s a complement. Sometimes you don’t need to do anything other than pass an error up the chain.
I would rather every developer takes a second while writing out “if err != nil” to decide how to add context or maybe return a new error with useful metadata.
Because it doesn’t skip the call chain - each function must explicitly handle the error or pass it on. In practice usually errors are handled one or two levels up, not with some global error handler as people do with exceptions. Also the error is in the function signature, unlike exceptions. Also, you don’t use try everywhere, that’s the point. They could do with some better examples.
> Because it doesn’t skip the call chain - each function must explicitly handle the error or pass it on So like, checked exceptions? > Also the error is in the function signature, unlike exceptions. So like, checked exceptions?
Sure, there are different ways of doing this. But the OP didn't say 'checked exceptions'.