Out of curiousity: Aside from "returning errors" and "throwing exceptions", is there any interesting research into other ways of error handling?
Why I’m not leaving Python for Go
81–90 of 245 posts
Re: Why I’m not leaving Python for Go
#82Earlier quoted context omitted.
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…
I don't know about Go, but lint is commonly used to enforce checking of return values in C. Presumably Go could bake an option into the compiler to enforce this too.
In Go unused variables are an error, so you are forced to either handle errors or explicitly ignore them (by assigning them to _).
Re: Why I’m not leaving Python for Go
#83I am eternally asking myself how do people handle exception in multi-threading programs ?
Not that error code solve the issue at all, but it look easier (less complex) to handle thread error with error code
Re: Why I’m not leaving Python for Go
#84I'm not in love with this aspect of Go either, and I also find that the idiom for dealing with it (multiple return values and multi-statement if conditional clauses) doesn't play well with Go's scoping rules, so that I find myself regularly having to decide between cleaner conditional or an explicit variable declaration. I also don't love how it makes my code look like my teenage-years C code. But I also think this i…
Incidentally, who "leaves" a language?
I started programming almost 30 years ago. Some languages I haven't touched in decades: BASIC, Fortran or Pascal. These days every time I have to use Java I hope it's the last. On the other hand, I used C for the first time 25 years ago. I don't use it very often but I wouldn't say I've left it.
So yes, people leave languages. And in many cases for good reason.
Re: Why I’m not leaving Python for Go
#85Earlier quoted context omitted.
Unless they're unchecked exceptions, of course. In Python, all exceptions are unchecked. The proliferation of checked exceptions all throughout the code is a whole other ball of wax.
Checked exception need to be handled properly. It depends on the sanity of the API. However, the standard way how to handle checked exception is a lot easier to maintain than error return values.
The only mainstream language that has checked exceptions is Java, and it is almost universally agreed, even within much of the Java programming community, that checked exceptions cause more problems than they solve.
Of course, unchecked exceptions have the problem that is basically impossible to keep track of what exceptions a function might throw (because it has to document all the exceptions that any functions it calls might throw too, and so on and on.)
In the end, of all error handling mechanisms around, Go is by far one of the best.
Re: Why I’m not leaving Python for Go
#86I am eternally asking myself how do people handle exception in multi-threading programs ? Not that error code solve the issue at all, but it look easier (less complex) to handle thread error with error code
Well, given how hopeless it is to try to do threaded programming with Python, I guess that is not a consideration Python programmers usually worry about.
Re: Why I’m not leaving Python for Go
#87I'll agree that this is perhaps the single thing that I don't like about Go. Now, you can argue it helps with "explicit error handling" and all that, but in that case you might as well have must-be-caught exceptions. Anyone want to fork Go?
What is it about panic/recover that forking the language , not merely using Go in a non-idiomatic way, would be necessary? I could see forking it to add generics in a way that the official guys aren't satisfied with, but why is that needed to use another style of error handling?
Anyone using panic/recover across API boundaries to emulate exceptions should have their brains gofmt-d.
But so far I have not noticed anyone doing this, perhaps because actually returning and handling errors properly is not as much of an issue as most people make it to be.
Re: Why I’m not leaving Python for Go
#88Earlier quoted context omitted.
> Errors are universally returned as type 'error' so to actually do anything with the error you have to first cast it to some specific type. But that type isn't part of the method signature so [...] This is quite correct and what's really broken with Go's approach to error handling and documentation.
I respectfully disagree. You almost never cast the error. Two approaches are common in the go community. 1. Error constants. These you can use == or a switch statement to do control flow with. 2. Custom Error Types. These you typically use a type switch which uses reflection to do dispatch off. In this case you might also then cast it if you need specific data off of the error but most of the time you don't need any…
I respectfully disagree: http://golang.org/src/pkg/net/timeout_test.go#L39
edit:
You should note that the above test code is actually far less verbose than the analogous end-user code, given that the timeout_test.go clearly expects the 'err' var to be a net.Error.
Now consider the case of a network subsystem, with funcs having in args of type 'bufio.Reader' and/or 'bufio.Writer'. At some prior point you may have set 'net.Conn.SetReadDeadline(aPointInTime)', and in your stream processing funcs you may naturally encounter either net.Error (due to timeout) or buffer overruns, etc.
What would call site look like? Can you safely cast to (net.Error) like the test code? Not unless you can live with panics on interface type mismatch.
// hmm. what is the error type?
_, e := readMessage(reader)
switch errType(e) { // you write this reflective func
case NET_ERROR:
if e.(net.Error).timeout() { /* handle timeout */}
default:
/* deal with other errors */
}Re: Why I’m not leaving Python for Go
#89Out of curiousity: Aside from "returning errors" and "throwing exceptions", is there any interesting research into other ways of error handling?
Common Lisp has an interesting exception system where errors have a chance to be handled without unwindind the stack. Basically, functions also receive an "error handling" object as an extra argument and they consult when they encounter an exception. The error handling object then edcides wether to continue operation, or to unwind back.
Re: Why I’m not leaving Python for Go
#90On the topic of when to use error-returns vs. when to use panic: I struggled with this aspect of Go coding too and what I decided was that, in order to choose your approach to errors, you should think about how important it is that your function can be composed into an expression: x := foo(a) + bar(b) vs. c, err := foo(a) if err != nil { ... } d, err := bar(b) if err != nil { ... } x := c + d It's a trade-off. By usi…
As I understand it, it is about severity. I think "panic" and "error" are meant to handle situations where there is no obvious, correct answer, like with array indexing. A nil pointer is another gimme example. Some languages have unchecked exceptions — maybe conceptualize it somewhat like that. panics() are for disasters, for serious program errors. By contrast, a network timeout is not a disaster. It's not "normal"…
Panic() should only be used to signal either programmer error, or truly panic-worthy situations where state is so messed up that crashing is the only good option.
Put another way: when you call an API correctly, it should be safe to assume it will never panic().
Panic/recover can be used in rare occasions within libraries to do more exception-ish style error handling, but those panics should never be allowed to escape and cross API boundaries.