I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
Good read.
But very one sided. Coin has two sides, there are languages which choose to have try catch and those which treat error flow as just one of flows, not a special language thing. And FP languages exactly do that(Elm or Haskell,Ocaml) instead of pair result, error which you have shown in Go there is Either (most probably you know what it is so will not continue). So Go really go in the se direction here.
So or we just use error as one of possible returns procedure/function can have or error have own special execution by try catch which skips call stack.
What problem I see in returning errors is that there can be many levels of such passing error around until we find a place which deals with that finally. With try catch we can just jump to the place where we handle it.
I am not sure that saying that Error and Exception are different things. Fact that you use some language feature which allows to jump doesn't mean that you cannot make proper error handling from that. I see try catch as just language construct. In many situation we just don't know what to do with some errors, there is just no alternative flow, it failed and game over so we throw and catch in the place where we say game over instead of juggling around and pretending that we know what to do.
Some time ago I also thought error as just return value is always the way to go. Now I see the trade-off in both solutions. But if language design bets on try/catch I would use it.
What problem I see in returning errors is that there can be many levels of such passing error around until we find a place which deals with that finally. With try catch we can just jump to the place where we handle it.
I love this too about exceptions. When my code mixes the actual logic with the error handling (if err != nil and the like), it gets very difficult to read. I like that try/catch lets the happy path flow naturally and you handle exceptions in one place.
Of course, you need to remember to handle the errors, but that's a price I'm willing to pay, rather than passing error objects around.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good read.
But very one sided. Coin has two sides, there are languages which choose to have try catch and those which treat error flow as just one of flows, not a special language thing. And FP languages exactly do that(Elm or Haskell,Ocaml) instead of pair result, error which you have shown in Go there is Either (most probably you know what it is so will not continue). So Go really go in the se direction here.
So or we just use error as one of possible returns procedure/function can have or error have own special execution by try catch which skips call stack.
What problem I see in returning errors is that there can be many levels of such passing error around until we find a place which deals with that finally. With try catch we can just jump to the place where we handle it.
I am not sure that saying that Error and Exception are different things. Fact that you use some language feature which allows to jump doesn't mean that you cannot make proper error handling from that. I see try catch as just language construct. In many situation we just don't know what to do with some errors, there is just no alternative flow, it failed and game over so we throw and catch in the place where we say game over instead of juggling around and pretending that we know what to do.
Some time ago I also thought error as just return value is always the way to go. Now I see the trade-off in both solutions. But if language design bets on try/catch I would use it.
I love this too about exceptions. When my code mixes the actual logic with the error handling (
if err != niland the like), it gets very difficult to read. I like that try/catch lets the happy path flow naturally and you handle exceptions in one place.Of course, you need to remember to handle the errors, but that's a price I'm willing to pay, rather than passing error objects around.