4 ms·

how does that work with try/catch? try/catch is significantly more verbose than just if err != nil // do something imo, and also much more brittle. Agree re: R

how does that work with try/catch? try/catch is significantly more verbose than just if err != nil // do something imo, and also much more brittle. Agree re: Results type in Rust and Ocaml, etc. Those are better in my view too. And yes, you can define a Result<any> return type in Typescript as well (and in fact that's what I mostly when I write typescript and works ok) but unlike Rust this is definitely not 'idiomatic typescript/js' and other developers who might not be familiar with Result types will probably initially dislike and then probably dismiss it.

lenkite 3y ago
There is no need to have try-catch at every function invocation. One can do this only at the level at which one needs to handle the error. In Go, every call made to a function is 5 statements and lines. Go code tends to bloat up the screen quite a bit and eyes glaze over. result, err := f() if err != nil { return nil, err // I don't want to handle this here but at callers.caller. } return result
scubbo 3y ago
> try/catch is significantly more verbose than just if err != nil // do something imo... Further to what the other replier said (about the ability to bubble-up errors), try-catch also lets you handle multiple errors in one block: ``` try { fileOutput1 = getSomethingFromFileSystem() fileOutput2 = getSomethingElseFromFileSystem() fileOutput3 = ... } catch (FileSystemException e) { // handle } ``` If I understand it correctly, GoLang's idiom would claim that this is a bad thing to do, and each error should be handled individually. Which - sure! That's _usually_ a reasonable, defensible, and safe position. But that means that GoLang's approach is always as verbose as its possible to be, whereas try/catch at least has the _possibility_ to condense handling. > ...and also much more brittle Can you be specific about what you mean by "brittle"? To me, it denotes a lack of flexibility - that is, if thing1 changes in an unexpected-but-still-legal way, then thing2 is likely to break. I can't see how that applies to try/catch-vs err-check - in both cases: * The exception/error is bound to a variable * (in most well-typed languages) the Type of the exception is checked by the type system, and/or (in every language, inc. GoLang) properties of the exception are checked by code * Something is done (a standard code action, a return/throw of an exception, or a program termination) You can write a brittle GoLang check (only checking for, say, `if e.message = "a very specific error message"`), and you can write a very flexible try/catch block (with a fallback `catch (Exception e) {doSomethingGeneric()}` - or, indeed, the _most_ flexible "try-catch" is "don't even catch it, let it bubble-up and let your framework/application handle it")

lenkite 3y ago

There is no need to have try-catch at every function invocation. One can do this only at the level at which one needs to handle the error. In Go, every call made to a function is 5 statements and lines. Go code tends to bloat up the screen quite a bit and eyes glaze over. result, err := f() if err != nil { return nil, err // I don't want to handle this here but at callers.caller. } return result

scubbo 3y ago

> try/catch is significantly more verbose than just if err != nil // do something imo... Further to what the other replier said (about the ability to bubble-up errors), try-catch also lets you handle multiple errors in one block: ``` try { fileOutput1 = getSomethingFromFileSystem() fileOutput2 = getSomethingElseFromFileSystem() fileOutput3 = ... } catch (FileSystemException e) { // handle } ``` If I understand it correctly, GoLang's idiom would claim that this is a bad thing to do, and each error should be handled individually. Which - sure! That's _usually_ a reasonable, defensible, and safe position. But that means that GoLang's approach is always as verbose as its possible to be, whereas try/catch at least has the _possibility_ to condense handling. > ...and also much more brittle Can you be specific about what you mean by "brittle"? To me, it denotes a lack of flexibility - that is, if thing1 changes in an unexpected-but-still-legal way, then thing2 is likely to break. I can't see how that applies to try/catch-vs err-check - in both cases: * The exception/error is bound to a variable * (in most well-typed languages) the Type of the exception is checked by the type system, and/or (in every language, inc. GoLang) properties of the exception are checked by code * Something is done (a standard code action, a return/throw of an exception, or a program termination) You can write a brittle GoLang check (only checking for, say, `if e.message = "a very specific error message"`), and you can write a very flexible try/catch block (with a fallback `catch (Exception e) {doSomethingGeneric()}` - or, indeed, the _most_ flexible "try-catch" is "don't even catch it, let it bubble-up and let your framework/application handle it")