casualsuperman2

The current weekly release has (and Go v1 will have) runtime.NumCPU() so you can do runtime.GOMAXPROCS(runtime.NumCPU())

And then in the code for handling the error, you can do

   switch err.(type) {
      case db.IOError:
          // Database exception here
      case io.FileNotFoundError:
          // File exception
      default:
          // Pass it to our caller for them to handle.
          return nil, err
   }

Which gives you the ability to selectively catch errors based on type.

In Go, the accepted way to report errors is to take advantage of multiple returns, such as:

   result, err := somePotentiallyFailingFunction()
   if err != nil {
      // Try to recover here
      ...
      // Not recoverable?
      panic()
   }

And this call to panic works the way you prefer. Note that doing the following:

   result := somePotentiallyFailingFunction()

won't compile since the number of values on the left doesn't match the right, so if a function can fail and returns an error, you will know. If you do something like:

   result, err := somePotentiallyFailingFunction()

And then never check err, it's actually a compile-time error, which enforces error checking, to a point. What's next is the kind of thing you don't like, and it's poor style.

   result, _ := somePotentiallyFailingFunction()

This assigns the error to _, which causes no errors if you don't use it.

Hope this clears some things up.

12. I was coding JavaScript for ProBoards. I shudder just thinking about it.