Someone can fix this by creating and popularizing a simple preprocessor that implements a macro called "safely" that expands to something like "call this function, and then if it errors, report the error to STDERR and abort execution". Then just prefix the majority of your commands with "safely", and implement your own error-handling in the few cases where you care.
Why I’m not leaving Python for Go
121–130 of 245 posts
Re: Why I’m not leaving Python for Go
#122Heh, I thought the answer was "Because my blog is named uberpython and it would be way confusing." :-) But error handling is one of those topics that really gets people going. From ABEND in the old IBM batch days, to uncatchable signals like SEGV in unix and uncaught exceptions in C++ or Java. I tend to come down on the "decide what you are going to do in the code, right where the error occurs" flavor of the argument…
> to uncatchable signals like SEGV in unix and uncaught exceptions in C++ or Java.
SEGV can be caught. There are only 3 uncatchable signals: KILL, STOP and CONT.
Re: Why I’m not leaving Python for Go
#123Earlier quoted context omitted.
The following illustrates how you use Go errors as if they were exceptions: func A() error { err := compute.Something() if err != nil { return err } return nil } Throwing errors up the return chain using error values is really very little different than throwing up the return chain using exceptions, except that now there is only one way to return, and it is always clearly marked. You return where you say "return". An…
How is that different from func A() error { return compute.Something() }
My point is that whether it's "A() error" or "A() (int, error)", whether it calls one function or three, what it's doing with the error is throwing it up the line, rather than handling it locally. Exactly as if it had said "throw err". So yeah, your version is what I'd shorten it to in practise, it just wasn't quite so illustrative.
Re: Why I’m not leaving Python for Go
#124As usual in these threads about Go, I really wish people would consider Haskell as a nice alternative. A lot of people write Haskell off as "academic" or "impractical", which I feel is not an entirely fair assessment. Particularly: Haskell is fast, concurrent by design (whatever that means, I'm sure Haskell is :P), typed but not cumbersome or ugly (less cumbersome and ugly than Go's types, even) and--most importantly…
This kind of comment kinda misses the point. Haskell (IMHO) won't ever be mainstream for much the same reasons Lisp never was (or will be?): it has an incredibly high learning curve (eg [1]). This is really the problem of the "pure" functional languages. Functional programming is suited to some tasks. With others the fit is almost tortuous. Imperative programming is well-suited to how we think and how we break down t…
This kind of comment kind of misses the point. The monadic style of threading error values is perfectly compatible with imperative programming if only language designers knew about it.
Re: Why I’m not leaving Python for Go
#125Earlier quoted context omitted.
The following illustrates how you use Go errors as if they were exceptions: func A() error { err := compute.Something() if err != nil { return err } return nil } Throwing errors up the return chain using error values is really very little different than throwing up the return chain using exceptions, except that now there is only one way to return, and it is always clearly marked. You return where you say "return". An…
What am I missing here? This appears to be fully in-band and contains a redundant code path (constituting a NaN bug in languages with incomparable NaN—no idea if that applies to Go) for no apparent reason.
What you're missing is that I'm showing how error throwing and error returning are functionally the same, when you have a standard error type, multiple valued return, and an idiom of returning errors you chose not to handle.
Re: Why I’m not leaving Python for Go
#126I have mixed feelings about errors as return codes. Then again, I have mixed feelings about exceptions. There are two general use cases for exceptions: 1. Unexpected (typically fatal) problems; 2. As an alternative to multiple return values. (1) is things like out of memory errors. (2) is things like you're trying to parse a user input into a number and it fails. I despise (2) for exceptions. It means writing code li…
Python doesn't have defer/panic, but it does have "with" statements which solve this issue in a RAII-like style:
with open('foo') as f:
# do stuffRe: Why I’m not leaving Python for Go
#127I have mixed feelings about errors as return codes. Then again, I have mixed feelings about exceptions. There are two general use cases for exceptions: 1. Unexpected (typically fatal) problems; 2. As an alternative to multiple return values. (1) is things like out of memory errors. (2) is things like you're trying to parse a user input into a number and it fails. I despise (2) for exceptions. It means writing code li…
Ad your last Python example - the preferred method of doing resource cleanup in Python is the 'with' mechanism:
with open("x.txt") as f:
#do stuff with f
Re: Why I’m not leaving Python for Go
#128Earlier quoted context omitted.
> No other approach to error handling is less fraught. The thing that kills me about Go's error handling is you return error AND value all the time. It's like an Either that always has Left and Right. I think it's a bummer, especially coming from a group that has developed languages in the past.
I imagine that this is to keep compatibility with C. And also, this ensures that when a Left value is accidentally read as a Right one, you don't get a "random" bit pattern due to type punning, but a correct (albeit meaningless) value such as NULL.
I'm not sure how, C doesn't have multiple return values either. I also don't really understand the second part. How is that any worse than the current situation of not checking the error side and reading an undefined (or whatever it is?) value?
Re: Why I’m not leaving Python for Go
#129As usual in these threads about Go, I really wish people would consider Haskell as a nice alternative. A lot of people write Haskell off as "academic" or "impractical", which I feel is not an entirely fair assessment. Particularly: Haskell is fast, concurrent by design (whatever that means, I'm sure Haskell is :P), typed but not cumbersome or ugly (less cumbersome and ugly than Go's types, even) and--most importantly…
I love Haskell too, but I always run into problems with distributing my compiled haskell binaries to other systems that don't have a GHC compiler available to them.
For example, if I compile a binary on my Ubuntu machine and SCP it to a server running centOS Linux, the binary just fails to run because of shared lib issues.
Even if you try and compile the binary statically I still run into similar problems.
This is in stark contrast to any Go/D/C/C++ binary which works fine
Re: Why I’m not leaving Python for Go
#130If you use a language that uses error codes, then you're forced to explicitly think about what to do in every single error case (or not, and accept the consequences). This can add a lot of mental overhead, but can result in a much more robust and well-thought-out program. But because more logic is involved period (to handle the robustness), the program is necessarily more complex. If you use exception handling, then…
The default behavior for an error in a programing language with exceptions is to crash. This gets your program back to a known state (i.e. not running). It's impossible for code to blindly continue when something bad happens. If you want to handle some error in a way other than crashing, handle it. Web frameworks usually catch exceptions that arise while a request is being handled, finish the request, and keep handli…
> The default behavior for an error in a programing language with exceptions is to crash. This gets your program back to a known state (i.e. not running). It's impossible for code to blindly continue when something bad happens.
In Smalltalk, the default behavior for an error is pretty much business as usual, because exception handling is mostly just Smalltalk code running normally. In some Smalltalks, you can override the "top level handler" and ensure that an app never crashes. (An infinitely growing collection will exhaust heap and crash the program that way.)