3 ms·
> 2. In particular, if a change causes a deeply nested function that used to always succeed to be able to error, the entire path up the call graph needs to get
by kccqzy 5y ago
> 2. In particular, if a change causes a deeply nested function that used to always succeed to be able to error, the entire path up the call graph needs to get Resultified.
This is a pro not a con. It now shows clearly that all these function calls are now failable. Of course at higher levels you may have additional assumptions that you know won't make the low-level functions fail, and you are welcome not to change everything as well.
> 4. They aren't a total solution, exceptions usually have to exist anyway (eg panic), for things like oom/assert/etc. So you're usually paying the cost of them anyway.
Panics do not need to be caught and handled. You can (and should) transform panics into abort.
- mwcampbell 5y ago> Panics do not need to be caught and handled. You can (and should) transform panics into abort. I think this strong stance needs some justification, especially since it's not the default in Rust.
- lanstin 5y agoIt is in Go Lang which shares error handling philosophy with GP.
- ziml77 5y agoGo panics do not simply abort. "For a real-world example of panic and recover, see the json package from the Go standard library. It encodes an interface with a set of recursive functions. If an error occurs when traversing the value, panic is called to unwind the stack to the top-level function call, which recovers from the panic and returns an appropriate error value (see the ‘error’ and ‘marshal’ methods of the encodeState type in encode.go)." From https://go.dev/blog/defer-panic-and-recover https://go.dev/blog/defer-panic-and-recover
- lanstin 5y agoBut philosophically, they should just abort.