

Show HN: Try/Catch/Finally experiment in Go - manucorporat
https://github.com/manucorporat/try

======
robert_tweed
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.

~~~
manucorporat
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.

~~~
dead10ck
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?

~~~
manucorporat
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](https://github.com/manucorporat/obme-
ios/blob/master/obme.h)

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

------
heavenlyhash
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](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.

------
manucorporat
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.

------
koenigdavidmj
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.

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

~~~
manucorporat
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
          })
      }

