3 ms·

Exception error handling is implicit because we don't know which line inside a try block can throw an exception. However, Go's `if err != nil` is not more expl

Exception error handling is implicit because we don't know which line inside a try block can throw an exception. However, Go's `if err != nil` is not more explicit than, for example, Rust's question mark operator. The former is more verbose than the latter, yes. But both are explicit in that we can know which line can return an error. The `if err != nil` is probably okay if there are only a few lines that can return an error, but if most lines in a function can return an error, it will result in too much noise. A real world example where panic is abused as an exception-like approach because the "proper" error handling using `if err != nil` is way too verbose: https://pkg.go.dev/github.com/apple/foundationdb/bindings/go/src/fdb#hdr-On_Panics https://pkg.go.dev/github.com/apple/foundationdb/bindings/go... (Actually Go's stdlib too sometimes abuses panic in a similar way.)

vips7L 5y ago
> Exception error handling is implicit because we don't know which line inside a try block can throw an exception You just need to have some thought when writing your code: let a; try { a = someFailingFunc(); } catch (e) { // handle } // use a // do work
- simiones 5y ago
  The whole point of Exceptions is to avoid writing try/catch all over the place. Let's take an example of idiomatic exception-based code: func doRequests(url1, url2 string) resp throws HttpException { resp1 := http.DoRequest("POST", url1) resp2 := http.DoRequest("GET", url2 + resp1.ID) return resp2 } vs func doRequests(url1, url2 string) (resp, error) { resp1, err := http.DoRequest("POST", url1) if err != nil { return nil, fmt.Errorf("Error in req1: %w", err) } resp2, err := http.DoRequest("GET", url2 + resp1.ID) if err != nil { return nil, fmt.Errorf("Error in req2: %w", err) } return resp2, nil } Of course, we can write the second example with try/catch as well, but the whole point of exceptions is to be able to write the first one when appropriate.
  - vips7L 5y ago
    > The whole point of Exceptions is to avoid writing try/catch all over the place Of course. I'm talking about when you actually handle your exceptions you should be specific about the lines you're handling.

vips7L 5y ago

> Exception error handling is implicit because we don't know which line inside a try block can throw an exception You just need to have some thought when writing your code: let a; try { a = someFailingFunc(); } catch (e) { // handle } // use a // do work

simiones 5y ago
The whole point of Exceptions is to avoid writing try/catch all over the place. Let's take an example of idiomatic exception-based code: func doRequests(url1, url2 string) resp throws HttpException { resp1 := http.DoRequest("POST", url1) resp2 := http.DoRequest("GET", url2 + resp1.ID) return resp2 } vs func doRequests(url1, url2 string) (resp, error) { resp1, err := http.DoRequest("POST", url1) if err != nil { return nil, fmt.Errorf("Error in req1: %w", err) } resp2, err := http.DoRequest("GET", url2 + resp1.ID) if err != nil { return nil, fmt.Errorf("Error in req2: %w", err) } return resp2, nil } Of course, we can write the second example with try/catch as well, but the whole point of exceptions is to be able to write the first one when appropriate.
- vips7L 5y ago
  > The whole point of Exceptions is to avoid writing try/catch all over the place Of course. I'm talking about when you actually handle your exceptions you should be specific about the lines you're handling.