5 ms·

Regarding Golang's if-hell e.g. in https://github.com/kabukky/journey/blob/master/database/update.go https://github.com/kabukky/journey/blob/master/database/upd

• pdq 11y ago
  No, panic/recover is a major hack. Rob Pike has written ideas here on how to clean up error handling if-blocks: http://blog.golang.org/errors-are-values http://blog.golang.org/errors-are-values
  • burntsushi 11y ago
    No, it's not a "major hack." That blog post is excellent, but it just doesn't always apply. The panic/recover idiom is extremely useful in parsers. For example, Go's JSON decoder: http://golang.org/src/encoding/json/decode.go http://golang.org/src/encoding/json/decode.go
    • pdq 11y ago
      The difference is that in parsers, errors are almost certainly fatal. As opposed to a runtime SQL error, where it could be a user error, value error, or other database error, which can be recovered from. Panic/recover are usually meant to catch "coding" and "assertion"-type errors (null pointers, array overflows, etc), not runtime errors. The latter is what the "error" values are used for.
      • thirsteh 11y ago
        Panic/recover is no problem as long as it does not traverse API boundaries, i.e. affects the user of your package, unless it really is a "fatal user error" in a function that wouldn't otherwise return an error.
      • burntsushi 11y ago
        I'm pretty sure you've misunderstood. Did you read the code I linked you to? Look at how it handles errors internally. Go's standard JSON decoder isn't going to crash your program if it fails to parse JSON---that would be disastrous. It exposes regular errors to the user. But internally, it uses panic/recover because it elides a lot of manual error checking.
  • superuser2 11y ago
    Interesting. That's basically the Maybe monad.
• dpritchett 11y ago
  I have never messed with panic, I read that code and I think I'd make a function that takes functions - the error handling response is the same every time. Maybe even put the list of calls in an actual list and invoke them with an iterator.
• lorddoig 11y ago
  I haven't written go in a while, but I recall being rather dissatisfied with the so-called 'if-hell'. I've been wondering lately - is there any reason why you couldn't/shouldn't use monads for this? Nothing obvious popping out of Google. "gonads" would be my choice of name for this library.
  • rlp 11y ago
    Love the name! But there's no way Go's feeble type system supports anything remotely like a Monad.
    • stcredzero 11y ago
      Here's what GIlad Bracha might say about that: http://www.infoq.com/presentations/functional-pros-cons?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=QConSanFrancisco2013 http://www.infoq.com/presentations/functional-pros-cons?utm_...
• tptacek 11y ago
  Since they're wrapping things in transactions anyways, they could just defer the error check to the end (or for that matter rework their interface to the database to stop after the first error is detected).
• vardump 11y ago
  Explicit error recovery is not hell, it's a blessing. Much easier to understand and to maintain than exception handling.
  • tomjakubowski 11y ago
    There is a third way. See Haskell's Either l r, or Rust's Result<T, E> types. See http://lucumr.pocoo.org/2014/10/16/on-error-handling/ http://lucumr.pocoo.org/2014/10/16/on-error-handling/ and http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ I don't know why so often, the immediate reaction to legitimate criticism of this wart in Go is to argue against exceptions, even when nobody has even brought up exceptions as an alternative.
    • thirsteh 11y ago
      In fact, Either/Maybe can function like safer versions of both paradigms: Functors allow you to build a program of many functions that will terminate with 'Nothing' or 'Either l' as long as any one of them experiences an error, without thinking about errors, and it still lets you explicitly handle any errors if you want to, this time on the sum type Maybe or Either, meaning that you usually handle both the error and non-error case, or receive a compiler warning. I agree that, probably universally, the people who fervently argue for either exceptions or explicit Go-style error handling don't know about Maybe/Either/Result. Then again, all this is pretty much impossible to replicate in Go.
    • vezzy-fnord 11y ago
      Option types are nice. The fourth way (and I think the best) is supervision trees, though this is more applicable when you have multiple units of execution... which Go does, so not having something similar out of the box seems strange. That said, even something as simple as errors being literal values that you can pattern match on is surprisingly versatile. Exceptions don't necessarily have to be awful weights that spill down all over the call stack, either. They can be distilled to a more basic catch/throw mechanism for shuffling around error properties and states.
• arthurbrown 11y ago
  I've written a tiny package that does just that in a controlled way, using named returns to bubble the error out. https://github.com/dagoof/failure https://github.com/dagoof/failure [Docs] https://godoc.org/github.com/dagoof/failure https://godoc.org/github.com/dagoof/failure
• 4ydx 11y ago
  https://gist.github.com/4ydx/70b732c15d83c294c7dd https://gist.github.com/4ydx/70b732c15d83c294c7dd
  • 4ydx 11y ago
    This is a simple way of dealing with repetitive error handling.