3 ms·

I suppose it's all a matter of taste. The error handling design decision is one thing I really like about Go. I write high reliability embedded software and "th

by zik 14y ago

I suppose it's all a matter of taste. The error handling design decision is one thing I really like about Go. I write high reliability embedded software and "throw/catch" just doesn't cut it for me since it obscures possible error conditions thrown from subroutines. I want to have to explicitly deal with those errors whenever they might occur and error returns are a good way of doing that. For every language feature someone likes there's someone else who hates it, and vice-versa.

je42 14y ago
I cant follow. Throw/Catch is as powerful as a error return value but it does not let you ignore errors without writing any code.
- wonderzombie 14y ago
  Unless they're unchecked exceptions, of course. In Python, all exceptions are unchecked. The proliferation of checked exceptions all throughout the code is a whole other ball of wax.
  - je42 14y ago
    Checked exception need to be handled properly. It depends on the sanity of the API. However, the standard way how to handle checked exception is a lot easier to maintain than error return values.
    - wonderzombie 14y ago
      Easier to maintain how? I don't think I see it. Return values, at least as a mechanism, are strictly simpler; they do not introduce new control flow. They just use "return." Control always reverts to the caller. For an exception, you don't know whether it's the caller, the caller's caller, some generic exception handler, or what. It's no fun trying to track down all of the callers of A, some subset of which might not catch exception X, then track down the subset of those callers which catch X. Otherwise adding or removing error codes seems equivalent to adding or removing exceptions. Same with trying to decide which exceptions/errors to handle or bubble up.
    - luriel 14y ago
      The only mainstream language that has checked exceptions is Java, and it is almost universally agreed, even within much of the Java programming community, that checked exceptions cause more problems than they solve. Of course, unchecked exceptions have the problem that is basically impossible to keep track of what exceptions a function might throw (because it has to document all the exceptions that any functions it calls might throw too, and so on and on.) In the end, of all error handling mechanisms around, Go is by far one of the best.
polemic 14y ago
But throw/catch gives you the option to do it that way if you want. An if/else per statement is no different from a try/catch per statement. The point of the post is that Go doesn't give you the option, whereas Python let's you decide when and how you'll deal with it.

by zik 14y ago

je42 14y ago

I cant follow. Throw/Catch is as powerful as a error return value but it does not let you ignore errors without writing any code.

wonderzombie 14y ago
Unless they're unchecked exceptions, of course. In Python, all exceptions are unchecked. The proliferation of checked exceptions all throughout the code is a whole other ball of wax.
- je42 14y ago
  Checked exception need to be handled properly. It depends on the sanity of the API. However, the standard way how to handle checked exception is a lot easier to maintain than error return values.
  - wonderzombie 14y ago
    Easier to maintain how? I don't think I see it. Return values, at least as a mechanism, are strictly simpler; they do not introduce new control flow. They just use "return." Control always reverts to the caller. For an exception, you don't know whether it's the caller, the caller's caller, some generic exception handler, or what. It's no fun trying to track down all of the callers of A, some subset of which might not catch exception X, then track down the subset of those callers which catch X. Otherwise adding or removing error codes seems equivalent to adding or removing exceptions. Same with trying to decide which exceptions/errors to handle or bubble up.
  - luriel 14y ago
    The only mainstream language that has checked exceptions is Java, and it is almost universally agreed, even within much of the Java programming community, that checked exceptions cause more problems than they solve. Of course, unchecked exceptions have the problem that is basically impossible to keep track of what exceptions a function might throw (because it has to document all the exceptions that any functions it calls might throw too, and so on and on.) In the end, of all error handling mechanisms around, Go is by far one of the best.

polemic 14y ago

But throw/catch gives you the option to do it that way if you want. An if/else per statement is no different from a try/catch per statement. The point of the post is that Go doesn't give you the option, whereas Python let's you decide when and how you'll deal with it.