13 ms·

let foo; try { foo = await is_this_better(); } catch (err) { console.log("if err != nil doesn't seem so bad all of a sudden"); }

by icholy 5y ago

lostcolony 5y ago
receive {lack_of_erlang_error_handling_is_a_missed_opportunity, true} -> ok after 0 -> throw let_it_crash end.
ryeguy 5y ago
This comparison misses the point. Go requires you to bubble up errors manually, that's the difference.
- randomdata 5y ago
  At least one can respect Go for being consistent, even if requires a little extra manual labour. The languages that require you to manually bubble up some types, but not others, are just bizarre. Like, they're onto something neat, but why stop halfway? I don't want to put in the manual work for any type. If I've decided the manual effort is worthwhile, I don't want weird exceptions to worry about. Pick a lane, programming languages.
mFixman 5y ago
func ThisCouldUseExceptions() error { err := Exceptions() if err != nil { return terrors.Propagate(err) } err = GeneraliseBetter() if err != nil { return terrors.Propagate(err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return terrors.Propagate(err) } value, err := AlsoTheyHelp() if err != nil { return terrors.Propagate(err) } chained_val, err := WithChaining(value) err = AndPreventAccidentallyIgnoringErrors(chained_val) if err != nil { return terrors.Propagate(err) } }
- philosopher1234 5y ago
  func ThisCouldUseExceptions() error { err := Exceptions(arg) if err != nil { return fmt.Errorf("if a '%v' dev: %w", err) } err = GeneraliseBetter() if err != nil { return fmt.Errorf("has to actually: %w", err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return fmt.Errorf("read these errors: %w", err) } value, err := AlsoTheyHelp() if err != nil { return fmt.Errorf("they will actually be: %w", err) } chained_val, err := WithChaining(value) if err != nil { return fmt.Errorf("useful: %w", err) } err = AndPreventAccidentallyIgnoringErrors(chained_val) if err != nil { return fmt.Errorf("this isnt a real problem: %w", err) } }
- nmilo 5y ago
  Generally I find if you're writing code like that, your code is too high level. Okay, you've propagated errors, but what is the calling code going to do with those errors? I find large functions like that usually have enough context to handle the errors themselves. Errors, after all, are just conditions with a special name. It's not common to propagate conditions up several layers of code, so why do the same with errors?
  - the_duke 5y ago
    Go doesn't have (automatic) backtraces. If you don't wrap errors with a trace or with a custom message you often have no idea where the error came from.
    - merely-unlikely 5y ago
      if err != nil { return mherr.WrapErr(err, "optional context") } I just wrote a custom function that adds the stack trace to the error. I also have it setup as a code snippet in VS Code so all I have to do is type "if err" and hit tab. Yes it looks a bit verbose but it adds approximately zero extra work and makes error handling extremely easy by default. Also, turn on log flags to add line numbers. log.SetFlags(log.Llongfile | log.LstdFlags)
throw_m239339 5y ago
Well you can actually put many exception yielding statements in the try, unlike with go where your code is full of "if err:=nil{}" after every potential error. Most of the time when an exception occurs in sequential operations that can fail, you don't really care where it failed exactly, only that the failure was caught. The irony is that Go does have half baked exceptions (panic,recover) on top of that error as value convention.
- philosopher1234 5y ago
  Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better.
  - throw_m239339 5y ago
    > Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better. No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in the language itself, it's with you and your team. Ironically I've seen a few Go libs and project trying to re-invent optional types due to the verbosity of Go errors, just like people were trying to roll their own generics with interface {} or code generation before they were added to the core. It's a demonstration that some developers don't like the status quo.
    - philosopher1234 5y ago
      > No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in the language itself, it's with you and your team. Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes it easy, which java fails at.

let foo; try { foo = await is_this_better(); } catch (err) { console.log("if err != nil doesn't seem so bad all of a sudden"); }

by icholy 5y ago

let foo; try { foo = await is_this_better(); } catch (err) { console.log("if err != nil doesn't seem so bad all of a sudden"); }

lostcolony 5y ago

receive {lack_of_erlang_error_handling_is_a_missed_opportunity, true} -> ok after 0 -> throw let_it_crash end.

ryeguy 5y ago

This comparison misses the point. Go requires you to bubble up errors manually, that's the difference.

randomdata 5y ago
At least one can respect Go for being consistent, even if requires a little extra manual labour. The languages that require you to manually bubble up some types, but not others, are just bizarre. Like, they're onto something neat, but why stop halfway? I don't want to put in the manual work for any type. If I've decided the manual effort is worthwhile, I don't want weird exceptions to worry about. Pick a lane, programming languages.

mFixman 5y ago

func ThisCouldUseExceptions() error { err := Exceptions() if err != nil { return terrors.Propagate(err) } err = GeneraliseBetter() if err != nil { return terrors.Propagate(err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return terrors.Propagate(err) } value, err := AlsoTheyHelp() if err != nil { return terrors.Propagate(err) } chained_val, err := WithChaining(value) err = AndPreventAccidentallyIgnoringErrors(chained_val) if err != nil { return terrors.Propagate(err) } }

philosopher1234 5y ago
func ThisCouldUseExceptions() error { err := Exceptions(arg) if err != nil { return fmt.Errorf("if a '%v' dev: %w", err) } err = GeneraliseBetter() if err != nil { return fmt.Errorf("has to actually: %w", err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return fmt.Errorf("read these errors: %w", err) } value, err := AlsoTheyHelp() if err != nil { return fmt.Errorf("they will actually be: %w", err) } chained_val, err := WithChaining(value) if err != nil { return fmt.Errorf("useful: %w", err) } err = AndPreventAccidentallyIgnoringErrors(chained_val) if err != nil { return fmt.Errorf("this isnt a real problem: %w", err) } }
nmilo 5y ago
Generally I find if you're writing code like that, your code is too high level. Okay, you've propagated errors, but what is the calling code going to do with those errors? I find large functions like that usually have enough context to handle the errors themselves. Errors, after all, are just conditions with a special name. It's not common to propagate conditions up several layers of code, so why do the same with errors?
- the_duke 5y ago
  Go doesn't have (automatic) backtraces. If you don't wrap errors with a trace or with a custom message you often have no idea where the error came from.
  - merely-unlikely 5y ago
    if err != nil { return mherr.WrapErr(err, "optional context") } I just wrote a custom function that adds the stack trace to the error. I also have it setup as a code snippet in VS Code so all I have to do is type "if err" and hit tab. Yes it looks a bit verbose but it adds approximately zero extra work and makes error handling extremely easy by default. Also, turn on log flags to add line numbers. log.SetFlags(log.Llongfile | log.LstdFlags)

throw_m239339 5y ago

Well you can actually put many exception yielding statements in the try, unlike with go where your code is full of "if err:=nil{}" after every potential error. Most of the time when an exception occurs in sequential operations that can fail, you don't really care where it failed exactly, only that the failure was caught. The irony is that Go does have half baked exceptions (panic,recover) on top of that error as value convention.

philosopher1234 5y ago
Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better.
- throw_m239339 5y ago
  > Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better. No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in the language itself, it's with you and your team. Ironically I've seen a few Go libs and project trying to re-invent optional types due to the verbosity of Go errors, just like people were trying to roll their own generics with interface {} or code generation before they were added to the core. It's a demonstration that some developers don't like the status quo.
  - philosopher1234 5y ago
    > No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in the language itself, it's with you and your team. Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes it easy, which java fails at.