I don't understand this complaint about Go. Either a function can result in an error or it can't. If it can result in an error and you don't handle that error, your program's behavior is undefined. Undefined behavior is a bad thing.™
Go forces you to handle the error (or explicitly ignore it). That design choice results in remarkably stable programs.
I completely fail at writing rust, but their implementation of error handling is much nicer.
Want to call a function, returning the error up to the caller on error? Instead of
res, err := somefunc()
if err != nil {
return err
}
let res = try!(somefunc());
let res = somefunc().unwrap();
let res = somefunc().expect("somefunc broke :(")
But that isn't really forcing you to do anything. There are 3 ways you can deal with an error: handle, ignore, or panic. In many cases go programs ignore errors when they really should panic.
It is disappointing that the go "equivalent" that you often see in examples is
res, _ := somefunc()
rust makes it impossible to ignore the error, while also making it easy to skip error handling if you just want to abort on failure.
if I could write code in go + rust generics + macros and not have to deal with the lifetime borrow checking crap, I would be so happy :-)
You might like OCaml. It's easy to write like Go but with a much more useful type system. Downside: concurrency is not as pleasant as in Go… at all. Then again, I see a lot of things written in Go that aren't particularly concurrent and just happen to use Go because the author wanted a moderately high-level compiled language with automatic memory management. OCaml is excellent for those.
(…Once you've used it for a bit. I admit it looks kinda weird at first.)
I recall Reason didn't yet support some important part of OCaml syntax, but I don't remember what that was.
Though I don't dispute that Reason is a good thing—Erlang saw a lot of growth from Elixir, hopefully Reason will get people into OCaml.
I agree; I find Reason to be a completely pointless project except if Facebook hopes to fracture the OCaml community.
But yeah, I also don't think the Reason syntax is that massive of an improvement: https://xivilization.net/~marek/blog/2016/05/19/reason-lets-...
if err := someFn(); err != nil { return err }
if err := someFn(); err != nil { panic(err) }
intval = convert("42").unwrap()
if intval, err := convert("42"); err != nil { panic(err) }
intval = convert("42")
intval, _ := convert("42")
intval := mustConvert("42")
in go, but 'must' type functions don't exist for every method in every library.
match somefunc() {
Ok(res) => res,
Err(e) => return Err(e)
}
res, err := somefunc()
if err != nil {
return err
}
Also, while I don't really know Go, doesn't
res, _ := somefunc()
Correct, with the minor note that it of course depends on your usage. If `res` is a pointer, any usage of it will panic because you ignored the err
This would be an absolutely terrible Go programmer. Like "I only log in as root to avoid typing sudo and my password" level retarded.
func magic() (int, error) {
a, err := foo()
if err != nil {
return 0, err
}
b, err := bar()
if err != nil {
return 0, err
}
c, err := baz()
if err != nil {
return 0, err
}
return a + b + c, nil
}
func magic() int throws SomeException {
return foo() + bar() + baz()
}
It's the multivalue return semantics that's the problem here. It's impossible to chain multivalue functions together to write anything succinctly. Worse yet, it's easy to simply ignore the error and create latent bugs because the first return value (which you're probably not ignoring) now has a "zero-value" which can be semantically valid. Whereas if I simply didn't catch the exception, it will be caught, perhaps by main(), but it will be caught, and I won't be populating my data structures with gibberish, which I can very easily do with Go.
"It's impossible to chain multivalue functions together to write anything succinctly"
Thus _you_ can choose the best approach based on _your_ needs. The following are _both_ examples of idiomatic Lua.
Example 1:
local v, errdesc, errcode = foo()
if not v then
if errcode == 1 then
...
elseif errcode == 2 then
...
else
error(errdesc)
end
end
local v = assert(foo())
local v = assert(foo(assert(bar())))
There are some errors that Lua will always throw, like memory allocation failures. These can be caught like any error, and the Lua VM is never put in an inconsistent state. But they're an example of the kind of non-specific error where you normally only catch them, if at all, at some logical transactional boundary--an image transformation in a photo editor, or a client request for a web server. Lua is, notably, one of the few scripting languages where allocation failure is recoverable. And rather trivially recoverable, in fact.
EDIT: error() is a specialized built-in: it's how you "throw" in Lua. But it will throw any value, not just a string.
Go is an interesting language when you have a project with dozens of developers, because it explicitly, by design, does not let you introduce any concept of "your needs". Go is not ashamed of the fact that it has one way of doing things, and that way is rarely elegant. But it _is_ effective.
My argument was only that multivalue error returns are not necessarily so limiting. Rather, IME they're a great compromise that can permit the best of both worlds. I always wondered why Lua's idiom was never picked up by Go. So much of Go seems lifted wholesale from Lua, or at least a shared ancestor. Particularly Go's goroutines, lexical closures, and how cleanly they interoperate; both of those constructs are much more limited in languages other than Go or Lua because of shortcuts taken to simplify the [pre-existing, broken] implementations (e.g. JavaScript and Python). But especially Go's exception mechanism, with syntax and semantics likewise almost identical to Lua's.
a, err1 := foo()
b, err2 := bar()
c, err3 := baz()
return a+b+c, errs.Combine(err1,err2,err3)Lol, I thought a long time about how I could express that feeling. now I understand, in Go the developer is doing the compiler's work ...
So:
if x, err := foo(); err != nil {
return 0, nil, err
}
x := check foo()
if err != nil {
return "", 0, err
}
return myStructType{}, nil
If all of the exception handling code is at the end of the block, you lose context (which of the three file opens the this FileNotFoundException), scope (every variable you want to use during cleanup has to be declared outside the try, initialized to a sentinel, and then checked in the catch to be sure the try initialized it to the real value), locality (the code, the error handling, and possibly the finally block all deal with the same things, and should be in sync, but are spread out), and more...
Error codes are verbose, but exceptions have issues to.
Neither one is ideal for me but error codes are the lesser of two evils for the time being.
Sometimes you don't care about the context. You can have middle-ware code: [top level code]<->[your code]<->[library]. Maybe you don't care if library throws a "disk full" exception or "network down", littering that part with "if err != nil ... " might not be the best solution. Top level code might decide to log the error, retry, retry and log, send a page, or even just let another layer on top of it decide.
But as you say it is a trade-off. At lest Rust provides a neat try! macro, it goes a long way in handling boilerplate.
let mut f = try!(File::open(filepath));
let a_byte = try!(f.read_u8());
I like seeing which parts of my program can fail, and I want to be forced to consider what should happen in different failure scenarios.
I like explicit error handling because not only is it obvious where my program can fail (and why), but it is obvious where it can't fail too.
With exceptions, any line of code may fail. Or maybe not. It is all invisible.
(Now this assumes a language that enforces return code checking; I use C and a static analysis pass today, but a few languages get this built-in).
> You can think of error handling as using case analysis to determine whether a computation was successful or not. As you will see, the key to ergonomic error handling is reducing the amount of explicit case analysis the programmer has to do while keeping code composable.
Yes, handling errors is important and should be done, however it need not result in a block of text that people just skim over and that is easy to get wrong.
Is there a more elegant way to handle errors in a concurrent language than returning error values? In general, exceptions do not work well within async programming. Too many JavaScript developers use exceptions and I advise to return errors instead. At least Go is consistent.
Exceptions do work well with synchronous programming, which is Go's model.
Can you elaborate on this? This doesn't seem true. For example, see Hello World: fmt.Println returns an error, which is implicitly ignored.
No, it doesn't. For example: https://play.golang.org/p/jGMmsaorez
Python is safe by default because you don't need to actively look for errors: when an error happens and there is no exception handling code you get a traceback, and the only way to ignore an exception is explicitly writing an (in)appropriate exception handling cause.
The problem is handling the error every time the function is called in the same place it is called and adding extra visual noise to the business logic.
Other ways to handle errors:
* Throw an exception. Program for the default happy path and throw an exception if something ... exceptional happened. This way code is not littered with 50% error handling which makes hard to read understand what it should be doing "normally". There is a trade-off there. But this has been implemented badly in other languages C++, Java and Go writers probably looked at that thought "No, way" and threw that idea away. I think Python does this right and it greatly goes to simplify code.
* Crash the goroutine (panic?). It is a bit like an exceptions but it applies to systems with concurrency units (goroutines, threads). However, in general that might not work as well because of two things -- shared memory, you can't just restart or assume a crashed goroutine hasn't scribbled over the heap memory, somehow or left data in an inconsistent state. And the other thing is goroutines don't have identifiers. so you can't say, I want to know if goroutine x crashes, then I want make sure y crashes as well, or I want to restart goroutine x and try again. But, that is not Go, that is Erlang / Elixir. Once you have seen process monitoring, linking, supervision trees and how they result in shorter, clearer code and less operational pain and suffering, it is hard to go back.
(Also if this sounds so alien and crazy, think about OS processes. A program has a pid. You can kill it using a pid, restart it. You know it hasn't scribbled over memory and messed up with other programs. This what sane operating systems do it has been this way for many decades, early Unix and then NT on windows. Other languages basically behave like Windows 3.1, which is cool, but is 1995 cool, not 2016 cool).
Should also mention Rust probably as well. Rust does a good job handling a lot proving there won't be data races at runtime between threads. Restarting a thread there is not as dangerous. But from what I guess still kind of awkward in the code. But even for the case explicit error handling, it has the try! macro which goes a good to visually simply the code. It does this because it decided that functions can return an agreed Result type which can be an ok value or an error. If it returns an ok, it passes the value along to the code that called, it if gets an error it returns early with the error. (Here it assumes both the caller and callee return Result. I don't know much about Rust so this might all be wrong, if anyone knows better please correct this ^).
I don't understand why "Go forces you to handle the error (or explicitly ignore it)". I find [a sample program](https://gobyexample.com/writing-files) and remove all the error checking code. Nothing unlike in Python happens. It compiles without warnings (even C can warn you about not using returned values).
I can see how Rust forces people to either handle the error, or explicitly ignore it. When you forget about it, it just doesn't compile.
There are way more advanced ways to handle errors than if err != nil boilerplate.
In before: Unchecked exceptions that I can forget about instead of always handling the errors gracefully or consciously pushing down the stack.
Not any more than you can forget about the returned error code in Go (val, _ := foo() etc). But with all the added convenience of exceptions.
What you'd seem to describe, and which Go lacks, are Optionals that you have to handle for every option.
And lots of other schemes (even Conditions).
I'm pretty sure that's an underscore right there, that very explicitly means "I'm consciously ignoring this error". Not sure what you're talking about with Optionals and Conditionals. Errors in Go are in the end structs that satisfy the error interface. That doesn't have to be an errors.Error, you can implement your own to satisfy more complex needs.
Unless you have very specific requirements for that one line, you don't go writing code like:
case f x of
Nothing -> Nothing
Just y -> case f y of
Nothing -> Nothing
Just z -> z
do
y <- f x
fyMind rewriting
do
y <- f x
fy
say with an example like response, err := http.Get(someURL)
How would this example look like in haskell if error handling is abstracted away?
resp, err := http.Get(someURL)
if err != nil {
return nil, err
}
res, err := DoStuff(resp)
if err != nil {
return nil, err
}
return res
do
resp <- http.Get(someURL)
DoStuff(res)
resp, err := http.Get(someURL)
if err != nil {
return nil, err
}
return DoStuff(resp) do
a <- operation1
operation2 a -- This one returns nothing
b <- operation3 a
c <- operation4 b
operation5 c
from math import sqrt
def f(a):
if (a >= 0):
return (True, sqrt(a))
else:
return (False, None)
def do(a):
(ok, y) = f(a)
if ok:
(ok2, y2) = f(y)
if ok2:
return (True, y2)
else:
return (False, None)
else:
return (False, None)
# example
for x in [2, -2]:
(ok, y) = do(x)
if ok:
print("Result: {}".format(y))
else:
print("Calculation failed.")
# Output
>>> Result: 1.189207115002721
>>> Calculation failed.
import Control.Monad (mapM_)
{-
Maybe Double represents a computation that either
returns a Double or fails. In this case, fail
when passed a negative number. Note: this is not
the same as throwing an exception.
-}
f :: Double -> Maybe Double
f x
| x >= 0 = Just (sqrt x)
| otherwise = Nothing
-- Fleshed out version of OP's snippet
eval :: Double -> Maybe Double
eval x = do
y <- f x
f y
{-
do notation desugars to monadic binding; in this
case eval can be desugared to the equivalent definition:
eval x = f x >>= f
-}
-- Here's why this is convenient, because you can pattern match
printIf :: Show a => Maybe a -> IO ()
printIf (Just x) = putStrLn $ "Result: " ++ show x
printIf Nothing = putStrLn "Calculation failed."
-- This is basically the equivalent of the Python for loop
main :: IO ()
main = mapM_ (printIf . eval) [2, -2]
f <$> f <$> x f x >>= f
By the way, is this the Civilization III armor? I never knew what model they got the image from. It is British... I always expected it to be German for some reason.