
Quick and Clean in Go - luriel
http://shadynasty.biz/blog/2012/07/30/quick-and-clean-in-go/
======
romaniv

      if err := http.ListenAndServe(":8080", nil); err != nil {
          panic(err)
      }
    

I've seen this kinds of stuff in PHP database APIs, and I've seen how much
smaller and more readable the codebase becomes with proper use of exceptions.
This is a huge downside of Go.

~~~
drivebyacct2
Conversely, this is a huge upside of Go. I enjoy the explicit error handling.
It's a very conscious decision. There is panic/recover style "exceptions" but
that's for truly exception states and not just error states.

It seems a rather bad example anyway, not sure why I'd prefer:

    
    
        try {
            http.ListenAndServe(":8080", nil);
        } catch(ServeException se) {
            // handle se
        }
    

over the Go alternative.

~~~
masklinn
In this precise case, the alternative would be:

    
    
        http.ListenAndServe(":8080", nil)
    

the uncaught exception would kill the task because, really, what is your http
server going to do aside from exit if it can't serve?

Not sure why you added a bunch of lines which end up doing _the exact
opposite_ of what the original code does.

~~~
romaniv
Exactly. It horrifies me that there are still programmers who don't understand
this after so many years of OOP advocacy.

The benefits of a properly designed (not Java-like, but C# or PHP like)
exception system stems from the fact that in the wast majority of cases you
_don't need to catch exceptions right away_. Most exceptions can be handled in
a few centralized locations higher up the stack. If you have 10 calls to
ListenAndServe, this means having 10 times less exception handling code.

Moreover, when you design a library and the users actually care about errors,
exceptions save you from needing to pass your error codes up the call chain
from deeply nested methods.

~~~
zemo
>If you have 10 calls to ListenAndServe

ListenAndServe blocks forever. If you have 10 calls to ListenAndServe, it's
implied that you're in 10 different, concurrently running processes
(goroutines). A panic, in Go, does not cross a goroutine boundary. If, in
imaginary parallel universe Go with exceptions, exceptions did cross goroutine
boundaries, then one goroutine could crash another goroutine.

The point of Go is to be able to sensibly write stable, concurrent programs
with compile-time safety. Exception-based error handling would be a mess with
Go's concurrency model.

In practice, you would only call ListenAndServe 10 times if you were listening
on 10 different ports, because you had 10 different projects on the same
server. That's a perfectly realistic situation. Now consider that one site has
an error and throws an exception. Should all the other sites go down?

Error handling in Go is admittedly tedious, but when you work with the
language for a bit you'll start to understand why they chose to design it in
that manner.

~~~
flogic
If Panic doesn't cross goroutine boundaries, why should exceptions?

~~~
drivebyacct2
The whole point is, it wouldn't make sense for them to cross goroutine
boundaries, but the pleasure of Go is the ease with which you can use
goroutines. Thus, in a lot of places where people would lazily use exceptions
to aggregate potential errors, you would be unable to because the exception is
occuring in a goroutine.

Which is why there are other nice ways of communicating such states in go that
go hand in hand with handling errors at their occurrence. If you find an error
in a goroutine, you can signal that on a channel, return and wait for a new
goroutine to be restarted in place of the errored one.

------
papaf
This is an excellent article (or I could be particularly stupid). I have been
playing with webapps using Go for about 6 months and this shows a much more
intelligent use of templates than the naive methods that I have been using.

------
knodi
I been playing around with Golang for about two weeks now and i must say I am
in love with it.

P.S. in my day time job i work with ruby.

------
mark_l_watson
That was a very nicely written article - thanks! I don't know Go (well, I am
good playing the game, but I don't yet use the programming language :-) and I
especially liked the way the MongoDB client code worked.

------
arrakeen
your $PS1 makes the commandline examples hard to follow

~~~
nakkiel
Focus on the subject at hand, not very minor details. Remarks concerning the
author should be addressed to him directly.

~~~
bluesnowmonkey
Likewise remarks to the author of a comment.

