5 ms·

Finally experiment in Go

29 points by manucorporat 12y ago

heavenlyhash 12y ago
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.
baq 12y ago
limited usefulness - can't return from the trying function. incidentally, try/finally and returns are what gives people funny facial expressions.
- manucorporat 12y ago
  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 }) }
robert_tweed 12y ago
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 12y ago
  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 12y ago
    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?
    - PuerkitoBio 12y ago
      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 https://github.com/eatnumber1/goal). Ken Thompson used to write quines (http://cm.bell-labs.com/who/ken/trust.html 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.
koenigdavidmj 12y ago
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.
manucorporat 12y ago
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.

29 points by manucorporat 12y ago

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.

baq 12y ago

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

manucorporat 12y ago
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 }) }

robert_tweed 12y ago

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 12y ago
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 12y ago
  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?
  - PuerkitoBio 12y ago
    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 https://github.com/eatnumber1/goal). Ken Thompson used to write quines (http://cm.bell-labs.com/who/ken/trust.html 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.

koenigdavidmj 12y ago

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.

manucorporat 12y ago

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.