←back to thread

257 points pmig | 2 comments | | HN request time: 0.676s | source
Show context
blindriver ◴[] No.43096757[source]
I've been using Go for a while now. The biggest headache is error handling. I don't care what the "experts" say, having exception handling is so, so, so much cleaner in terms of error handling. Checking for err is simply bad, and trickling errors back up the call stack is one of the dumbest experiences in programming I've endured in multi-decades. If they are willing to add generics, they should add exception handling as well.
replies(4): >>43097025 #>>43097105 #>>43097710 #>>43098949 #
bmurphy1976 ◴[] No.43097105[source]
To each their own. I'm not going to claim to be an expert, but as somebody who's been coding since the 80s it was a breath of fresh air to see Go do what I wanted languages to do all long instead of ramming exceptions down my throat. I have problems with Go (examples: slice behavior and nil type interfaces) but error handling is not one of them.
replies(1): >>43097199 #
CharlieDigital ◴[] No.43097199[source]
What challenge did you run into with exception handling?

I'm curious because I've never felt it being onerous nor felt like there was much friction. Perhaps because I've primarily built web applications and web APIs, it's very common to simply let the exception bubble up to global middleware and handle it at a single point (log, wrap/transform). Then most of the code doesn't really care about exceptions.

The only case where I might add explicit exception handling probably falls into a handful of use cases when there is a desire to a) retry, b) log some local data at the site of failure, c) perform earlier transform before rethrowing up, d) some cleanup, e) discard/ignore it because the exception doesn't matter.

replies(6): >>43097659 #>>43098169 #>>43098430 #>>43099302 #>>43100129 #>>43101696 #
hedora ◴[] No.43098430[source]
Exceptions are fine if you never catch them. So is calling abort(). (Which is the Unix way to do what you described.)

If you need to handle errors, you quickly get into extremely complicated control flow that you now have to test:

   // all functions can throw, return nil or not.
   // All require cleanup.
   try {
      a = f();
      b = a.g();
   } catch(e) {
      c = h();
   } finally {
      if a cleanup_a() // can throw 
      if b cleanup_b() // null check doesn’t suffice…
      if c cleanup_c()
   }
Try mapping all the paths through that mess. It’s 6 lines of code. 4 paths can get into the catch block. 8 can get to finally. Finally multiplies that out by some annoying factor.
replies(3): >>43098503 #>>43099540 #>>43100151 #
CharlieDigital ◴[] No.43098503[source]
Can you give the equivalent in Go?
replies(2): >>43099445 #>>43099650 #
1. CharlieDigital ◴[] No.43100880[source]
This is satire, right?
replies(1): >>43108274 #
2. ted_dunning ◴[] No.43108274[source]
No.

It is just an explicit rendition of a complex topic.

Do you have a more economical example that handles all of the corner cases of cleanup routines throwing errors?