Show HN: Try/Catch/Finally experiment in Go | Hacker News Reader

Finally experiment in Go

github.com

29 pointsmanucorporat11 comments

The usual response to this kind of thing among gophers is "don't do that", which is a reasonable response given that if the language designers thought Go should have try/catch/finally they'd have included them in the language.

As it is, they decided against it. Some may disagree with that, but the entire rationale is public and based on pragmatism. Go is a fairly opinionated language, so if you disagree strongly with those choices, you probably ought to pick another language. Part of the beauty and value of Go is that all Go code tends to read like all other Go code. Obfuscation and unnecessary abstraction are frowned upon.

In this case you can get much the same result with local functions and defer (which you are creating here anyway). There's little value in wrapping it up with this syntax other than to make your Go code less idiomatic.

I totally agree! just to leave it clear, I did not create it to be even used, it's an experiment.

I guess, it shows how powerful the panic(), recover(), defer can be, in my opinion much more than try/catch/finally.

A practical demonstration. Go even without explicit exceptions has the semantics needed to provide it exactly in the same way Java/C++ and Python does.

I'm truly not trying to be rude, but if you agree with the above point, then why did you make it publicly available? Only two outcomes can come of this:

1. Nobody uses it, for the reasons posted above.

2. People actually use it, which is bad, for the reasons posted above.

What you were trying to learn from this "experiment"? And what did you actually learn that is valuable to other people?

I am not trying to learn Go, I have been using it for years (without exceptions :) ) i believe clever hacks are usually helpful to open people's minds, don't you?

another examples, (not sure if you know objective-c). primitive type generics using macros + blocks: https://github.com/manucorporat/obme-ios/blob/master/obme.h

another example or a clever hack to break the limits ;)

I found it interesting to read. Seems like enough reason to me. We aren't running out of bits.

Maybe he did it for fun. Hacks don't have to be useful. Brad Fitzpatrick provided a Go solution to goal (https://github.com/eatnumber1/goal). Ken Thompson used to write quines (http://cm.bell-labs.com/who/ken/trust.html). No harm in doing so, especially when it is not wrongly marketed as some kind of useful problem-solving library.

This is very interesting. The difficulty in handling errors in large-scale golang programs is one of the primary practical issues I experience standing in the way of adopting it in sizable projects. Don't get me wrong -- defer() is very powerful.

Mostly. Where error handling truly gets high-friction is when you start having to deal with the idea that errors in golang are basically untyped; never mind that the entire rest of the language is typed, errors are not held to the same standards.

In small projects, this is something I can live with. In large projects, where any of three majorly different subsystems can fail, and they in turn manage other failable components, and I want to compose my error handling to deal with some of these but pass others up... golang has a very difficult time handling this situation. As a result, I'm very interested in libraries that explore the potentials in this area.

If you haven't seen spacemonkey's error handling library yet:

http://godoc.org/github.com/spacemonkeygo/errors

... it's a library that's worth a look, and I think using it in the next major golang project I start is going to dramatically improve the maintainability and stability.

I'd be very, very interested in seeing a combination of a smooth flow like this 'try' demo multiplied by typed errors. The ability to catch some types of errors would be very empowering.

I add a comment in the README ;)

  Experiment only!!

  I as a Go developer, do not recomend to use this library in production or real world code. The Go language was designed to do not use expections, instead use the explicit error management suggested in Effective Go. A good programmer MUST write idiomatic code.

  Instead you should use this project as a learning tool to understand the exceptions flow in a language like python/c++ and python.

  It also shows that Go, even without explicit exceptions has the semantics needed to provide it exactly in the same way Java/C++ and Python does.

I don't see how finally (especially with the unusual order) is much cleaner than defer. That's the main advantage of defer: the idiomatic way to use defer is right after the construction of the object in question, rather than half a screenful down like it would be in Java and friends.

limited usefulness - can't return from the trying function. incidentally, try/finally and returns are what gives people funny facial expressions.

yeah! I agree, it's just an experiment. Anyway, you could use the named return values to have a similar behaviour.

  func hello() (a int) {
      try.This(func() {
          a = couldPanic()
      }).Catch(_ try.E) {
          a = 0
      })
  }

Reply on news.ycombinator.com