undefined | Better HN

story

0 pointslinkdd4y ago0 comments

Ok I was wrongly assuming that panic was expecting an error type, in fact it's an interface{}.

> Your use of exceptions for flow control (i.e. goto) is considered harmful

Exceptions are a way to delegate error handling to the caller by giving them informations about the unexpected behavior. It implies that the expected behavior is the "happy path" (everything went well) and any deviations (errors) is unexpected.

This is far from a goto because you can have `try/finally` blocks without catch (or defer in golang).

Also, exceptions are just a kind of algebraic effects that do not resume. There was a proposal to JS for this: https://github.com/macabeus/js-proposal-algebraic-effects

This is also easier to test. assertRaises(ErrorType, func() { code... })

Almost every Go library I've seen just return an error (which is just a string), you'd need to parse it to assert that the correct error is returned in special conditions.

0 comments

randomdata4y ago

> It implies that the expected behavior is the "happy path" (everything went well) and any deviations (errors) is unexpected.

Errors are the "happy path", though. Your network connection was lost for the data you were trying to transmit so you saved it to your hard drive instead means that everything went well! Throwing your hands up in the air and crashing your program because you had to make a decision is not something you would normally want to do. If statements are present in most happy paths for good reason. That the inputs presented you with a choice does not remove you from the happy path.

Now, if you made a programming mistake and tried to access an array index that is out of bounds, then there isn't much else you can do but crash. Exceptions are appropriate for that kind of problem. They are exceptional in that they should never happen. Errors, on the other hand, are expected to happen and you can happily deal with them.

linkddOP4y ago

> Throwing your hands up in the air and crashing your program because you had to make a decision is not something you would normally want to do

And that's not something you do thanks to try/catch. You just handle the error where it's meaningful to handle it.

The happy path of "make a request" is that there is no network error.

The happy path of "make sure this request is sent" is that you handle the unexpected network error to save the request to disk for further retry.

If the disk is full, you're not on the happy path anymore.

In Erlang/Elixir, there is a philosophy of "let it crash" which is basically "delegate the error handling/recovery to where it's meaningful to do so". For example:

  start a supervised process to send a request
  if there is an unexpected network failure, let it crash
  the supervisor retries on its own

Or:

  start a process to send a request
  if there is an unexpected network failure, let it crash
  monitor the process to be notified when it crash
  do something if it happens, like saving the request to disk

A "write_file" function can return many kind of errors:

  - file not found (some folder in the path does not exist)
  - permission denied
  - disk full

When you call write_file, you might want to handle some of those errors, and delegate the handling of others to your caller.

You're still not addressing my main point. How do you check which errors you want to handle and which one you want to propagate with just a string describing your error ?

tptacek4y ago

You don't. That's why Go errors are typed. You use `errors.Is` to check if any of the errors in a chain of wrapped errors is of a particular kind. It doesn't grovel through strings to answer that question.

It is very weird that this subthread starts with "current state of the art".

randomdata4y ago

> And that's not something you do thanks to try/catch. You just handle the error where it's meaningful to handle it.

And it is always most meaningful to handle it immediately, so what's the point of introducing a application-wide goto jump, amid Dijkstra's warnings that doing so is harmful when you're just going to catch right away anyway?

> The happy path of "make a request" is that there is no network error.

If there is a network error, you're still happy. It is not like you screwed up as a programmer. What is there to be unhappy about? The network error input to your function is very much expected and part of the "happy path" as much as any other input to your application.

> if there is an unexpected network failure, let it crash

Network failures are never unexpected. It would be exceptional to never experience a network failure.

> How do you check which errors you want to handle and which one you want to propagate with just a string describing your error?

Why would your errors be strings? When errors are just plain old values like any other it is true that you could resort to using strings to represent errors, but it would be quite unidiomatic to do so. Kind of like how you can overload exceptions to handle errors, but just because you can does not mean you should.

j / k navigate · click thread line to collapse

0 comments

randomdata4y ago

> It implies that the expected behavior is the "happy path" (everything went well) and any deviations (errors) is unexpected.

linkddOP4y ago

> Throwing your hands up in the air and crashing your program because you had to make a decision is not something you would normally want to do

And that's not something you do thanks to try/catch. You just handle the error where it's meaningful to handle it.

The happy path of "make a request" is that there is no network error.

The happy path of "make sure this request is sent" is that you handle the unexpected network error to save the request to disk for further retry.

If the disk is full, you're not on the happy path anymore.

In Erlang/Elixir, there is a philosophy of "let it crash" which is basically "delegate the error handling/recovery to where it's meaningful to do so". For example:

  start a supervised process to send a request
  if there is an unexpected network failure, let it crash
  the supervisor retries on its own

Or:

  start a process to send a request
  if there is an unexpected network failure, let it crash
  monitor the process to be notified when it crash
  do something if it happens, like saving the request to disk

A "write_file" function can return many kind of errors:

  - file not found (some folder in the path does not exist)
  - permission denied
  - disk full

When you call write_file, you might want to handle some of those errors, and delegate the handling of others to your caller.

You're still not addressing my main point. How do you check which errors you want to handle and which one you want to propagate with just a string describing your error ?

tptacek4y ago

It is very weird that this subthread starts with "current state of the art".

randomdata4y ago

> And that's not something you do thanks to try/catch. You just handle the error where it's meaningful to handle it.

> The happy path of "make a request" is that there is no network error.

> if there is an unexpected network failure, let it crash

Network failures are never unexpected. It would be exceptional to never experience a network failure.

> How do you check which errors you want to handle and which one you want to propagate with just a string describing your error?

j / k navigate · click thread line to collapse