10 ms·
12 years and still no proper error handling. World stars. ;) Seriously, the error handling is a big problem with Go. Not the way it works, the way it effects ho
by AtNightWeCode 5y ago
12 years and still no proper error handling. World stars. ;) Seriously, the error handling is a big problem with Go. Not the way it works, the way it effects how people do control flow in general.
- mountainriver 5y agoIt’s never actually been a problem for me, I prefer Go errors over most languages
- AtNightWeCode 5y agoI can live with the error handling. But as I wrote. The problem is that it encourages if-programming. Something that is a problem in the Go community.
- handrous 5y agoIf it's helping keep the "'if' considered harmful" crowd away, I say keep it. There are plenty of other languages.
- mountainriver 5y agoYeah exactly, conditionals around errors are fine. Nothing like being pedantic for no reason
- mseepgood 5y agosince when is if-programming a bad thing
- skybrian 5y agoIt depends on what kind. I didn’t find maintaining codebases littered with platform-specific ifdefs all that fun. If statements used for error checking are a bit verbose but basically fine.
- mseepgood 5y agoGo doesn't have platform-specific ifdefs sprinkled throughout the source. Platform-specific code is separated into files guarded by build tags as recommended in 'The Practice of Programming'. Compile-time control flow is not mixed with runtime control-flow.
- skybrian 5y agoSure, that was in C. Go is an improvement.
- AtNightWeCode 5y agoWhat you learn at school when it comes to programming is to avoid if-statements for control flow. It is error prone. If-statements are mainly used for various types of guards.
- Thaxll 5y agovs exception based control flow which is way worse.
- mseepgood 5y ago'if' is the epitome of control flow (next to looping). It's fundamental to computer programming. It's honest. Don't be ashamed of control flow, don't hide your control flow as if it didn't exist.
- morelisp 5y ago> It's fundamental to computer programming. I'm weakly pro-if, but no, it's not. We went a lot of years without it, and some rending and gnashing accompanied its introduction.
- AnimalMuppet 5y agoAnd what you learn after a few years in the real world is that, when school tells you "this is the right way", they're almost always wrong. Or, there at least almost always wrong in many circumstances. The real world is a lot more complicated than they teach you in school, and the correct answer is almost always "it depends". Should you avoid if-statements? It depends. What are you going to have to do instead? You're going to have to do something. Is that something going to be more understandable for your co-workers for the lifetime of the code? Maybe, depending on your co-workers. Maintainability over the lifetime of the code far outweighs and "should" that they tell you at school.
- xh-dude 5y agoI really think Go’s opinion here arises from a sense that some abstractions of control flow just should be verboten for concurrency. For example exceptions dumping a stack trace in a concurrent program is often OK and occasionally extremely cursed.
- nobleach 5y agoSpectre I think? The mitigation patches make branch-heavy code slower.
- jrockway 5y agoI agree with this. What I like about the Go method is that all errors are equal -- they look the same if it's a stack of microservices running at different companies, a bunch of goroutines communicating state with each other, or if you're just calling a local function that fails. It's the same every time, and the programmer can cut through the noise and make a complicated error from a complicated system simple, concise, and easy to understand. People seem mad that they have to plumb around `err`, and that they have to provide useful context with fmt.Errorf. I see that as letting good programmers make good systems. The default in other languages is useless -- line numbers and arguments is all you are allowed to have, and when something goes wrong it takes up your entire screen with noise. Not as good as everyone thinks it is.
- fourseventy 5y agoThats your opinion. I love the error handling in go. I think its superior to the traditional try/catch approach most other languages use.
- nineplay 5y agoError handling is easily one of my favorite things about Go. No 'oops I forgot to put in a try/catch and now my code died with no explanation'. No 'I forgot a finally ( or didn't realize I needed one ) and now I'm leaking resources'. No 'should I return Null or false or an error code?'. No '20 log messages for the same error because every function is reporting it'. The Go model - Return err, always as the last parameter - When you need more context, add it to the error before you return it - There is a calling function that reports errors. Maybe main(), maybe a subscriber, maybe a goroutine. There can be other situations of course but the point is that there's a clear ownership. If someone is logging errors in a higher up method, they should be prepared to explain why in code reviews.
- AtNightWeCode 5y ago1. You have something that catches and logs all uncaught exceptions. 2. Defer is nice. As easy to forget as using in C#. 3. Always null/nil. Uncle Bob is plain wrong here. 4. Stack trace. But you should keep things wide and shallow. No matter what technology you use. In Go it is about as easy to swallow errors as with try-catch. But my post was more about how all the if-statements generates more unnecessary if-statements.
- ssteel 5y agoThe if-statements are not unnecessary if you want to handle errors in place and make the code highly readable. Just because you don't like it doesn't make it wrong.
- philosopher1234 5y ago>But you should keep things wide and shallow. No matter what technology you use. This is literally the exact opposite of what I believe, and the bane of my existence at work. Wide and shallow code is spaghetti. Too many APIs = continuous confusion and relearning.
- Thaxll 5y ago1. In most web server you have a panic middleware that does exactly that. By default in Go uncaught panic go to stdout.
- lawn 5y agoI find it fascinating that some hate it and others love it. I personally vastly prefer Rusts Result<T, Error> and Erlang/Elixirs {:ok, T} you pattern match on or crash the process and recover. The code is cleaner while it also makes harder to make mistakes.
- grey-area 5y agoI think a lot of Go programmers would agree with you. I prefer the current situation to exceptions but would like to see them try something more like Rust or Elixir at some point.
- kamaal 5y ago>>the way it effects how people do control flow in general. This. Most people are used to thinking in terms of try/catch. Programs exiting on exceptions. This is just one of those things like Garbage Collection. Its one of those things a modern programming language should do. The example is a bit like using automatic transmission cars. As much you can sing praises of a manual transmission cars(manual control, mileage etc) its just everyday programming is like driving in roads with heavy traffic, and whatever perceived poetic beauty a manual task could offer, the automated task works better if you have to do this for hours everyday. In many ways a language without try/catch semantics these days is dead on arrival for most shops.