9 ms·

> Not enough Go code adds context like os.Remove does. Too much code does only Well, the error interface is { Error()string } and gophers were told to use erro

> Not enough Go code adds context like os.Remove does. Too much code does only Well, the error interface is { Error()string } and gophers were told to use errors as values, not errors as type because supposedly "exceptions are bad". By providing context you are just re-inventing your own mediocre exception system. Why use errors as value at first place if you need context? just put exceptions in Go, therefore people don't need to use a third party library to wrap errors in order to trace the execution context.

0xCMP 10y ago
I think their views on this are changing from experience with the language. Part of the problem I think is that the way they wanted people to use the language isn't clearly explained on their posts about errors. Some how I read it over and over and I never quite get the gist of when they think I should create a custom error type or not.
echlebek 10y ago
Because Go considers errors to be values, and exceptions are control flow.
- hota_mazi 10y ago
  But there is value in providing a different control flow for errors, which is why exceptions have become prevalent in most programming languages in the past decades. The value is that your code's happy path is clean and not encumbered with error checks every ten lines, like we see in Go sources all the time. Separating the happy path and the error handling in different sections of the code contributes to clean code, especially if exceptions are checked and cannot be ignored by the developer.
  - sethammons 10y ago
    In my experience, separating the happy path from the error handling leads to unhandled errors. Just yesterday, one of our python projects (an API with about 600 endpoints) started barfing an error for non-parseable JSON because something at the top level caught it. I have no clue where it came from nor how to reproduce it. Had we been handling errors when and where they occur, I would have a vastly shorter debugging period in front of me.
    - hota_mazi 10y ago
      > In my experience, separating the happy path from the error handling leads to unhandled errors. No, the separation has nothing to do whether errors are handled or not. If error handling is mandated by the compiler (e.g. checked exceptions), there will be no unhandled errors since the compiler will simply refuse to compile your code until you handle these errors. Whether you handle these errors near the happy path or in a different section of the code is an orthogonal concern.
      - weberc2 10y ago
        Or people will simply elect to use unchecked exceptions, and users will see stack traces frequently. In either case, Go programs don't seem to suffer from bugs in the error handling paths like Java and friends. YMMV. I don't see the value in a clean happy path and a hidden error path.
        stouset 10y ago
        > Or people will simply elect to use unchecked exceptions Go already has unchecked exceptions. It's called "panic".
        weberc2 10y ago
        Ok? How does that relate to the discussion? What point are you intending to make?
        stouset 10y ago
        It completely invalidates your argument. Your argument is that an error-handling system as described would be undesirable because it would result in developers misusing unchecked exceptions. Go already has unchecked exceptions in the form of `panic`. So either developers are already abusing it, in which case go's current error-handling approach is no better than the one proposed according to your metric. Or developers have access to it but aren't abusing it, in which case there's no reason to expect they'd abuse it in a system where doing it the right way is even easier than it is today. In my experience, users already do experience stack traces as it's embarrassingly easy to accidentally operate on a nil pointer.
- coldtea 10y ago
  Errors must be handled, which means you always get control flow with them, even if it's just the primitive (if err != nil) -- in Go you just have to manually write the control flow instead of the language helping you.
  - echlebek 10y ago
    Right - the control flow is explicit, and works the same as regular control flow.
dilap 10y ago
I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. There's a whole lot of space between "include useful context in errors" and "exceptions". (And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.)
- throwaw199ay 10y ago
  > I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. As opposed to panics? Checked exceptions don't blow up in your face, you have to handle them. Nil errors and type errors might yet these also happen to Go. I see no difference with Java here. Go isn't better when it comes to error handling, in fact Go is extremely tedious when it comes to error handling. > (And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.) So Go has both(unchecked exceptions and errors as "value"), how does it make things better? it doesn't. If it did, the blog wouldn't be talking about people "handling errors the wrong way".
  - dilap 10y ago
    I've found it helpful to distinguish between errors that are program bugs and errors that are conditions of the outside world (network errors, invalid data, etc). I think it depends somewhat on the kind of software you're writing. Being very careful with errors is quite handy for a long-running server processes; maybe (maybe!) not so worth it for a program that starts and stops within the attention span of a single user.
    - pvg 10y ago
      errors that are program bugs and errors that are conditions of the outside world That also happens to be the intended distinction between Java's checked and unchecked exceptions.
  - hnbro 10y ago
    > you have to handle them the definition of "handle" widely varies, to the point of making the exercise near meaningless.

0xCMP 10y ago

I think their views on this are changing from experience with the language. Part of the problem I think is that the way they wanted people to use the language isn't clearly explained on their posts about errors. Some how I read it over and over and I never quite get the gist of when they think I should create a custom error type or not.

echlebek 10y ago

Because Go considers errors to be values, and exceptions are control flow.

hota_mazi 10y ago
But there is value in providing a different control flow for errors, which is why exceptions have become prevalent in most programming languages in the past decades. The value is that your code's happy path is clean and not encumbered with error checks every ten lines, like we see in Go sources all the time. Separating the happy path and the error handling in different sections of the code contributes to clean code, especially if exceptions are checked and cannot be ignored by the developer.
- sethammons 10y ago
  In my experience, separating the happy path from the error handling leads to unhandled errors. Just yesterday, one of our python projects (an API with about 600 endpoints) started barfing an error for non-parseable JSON because something at the top level caught it. I have no clue where it came from nor how to reproduce it. Had we been handling errors when and where they occur, I would have a vastly shorter debugging period in front of me.
  - hota_mazi 10y ago
    > In my experience, separating the happy path from the error handling leads to unhandled errors. No, the separation has nothing to do whether errors are handled or not. If error handling is mandated by the compiler (e.g. checked exceptions), there will be no unhandled errors since the compiler will simply refuse to compile your code until you handle these errors. Whether you handle these errors near the happy path or in a different section of the code is an orthogonal concern.
    - weberc2 10y ago
      Or people will simply elect to use unchecked exceptions, and users will see stack traces frequently. In either case, Go programs don't seem to suffer from bugs in the error handling paths like Java and friends. YMMV. I don't see the value in a clean happy path and a hidden error path.
      - stouset 10y ago
        > Or people will simply elect to use unchecked exceptions Go already has unchecked exceptions. It's called "panic".
        weberc2 10y ago
        Ok? How does that relate to the discussion? What point are you intending to make?
        stouset 10y ago
        It completely invalidates your argument. Your argument is that an error-handling system as described would be undesirable because it would result in developers misusing unchecked exceptions. Go already has unchecked exceptions in the form of `panic`. So either developers are already abusing it, in which case go's current error-handling approach is no better than the one proposed according to your metric. Or developers have access to it but aren't abusing it, in which case there's no reason to expect they'd abuse it in a system where doing it the right way is even easier than it is today. In my experience, users already do experience stack traces as it's embarrassingly easy to accidentally operate on a nil pointer.
coldtea 10y ago
Errors must be handled, which means you always get control flow with them, even if it's just the primitive (if err != nil) -- in Go you just have to manually write the control flow instead of the language helping you.
- echlebek 10y ago
  Right - the control flow is explicit, and works the same as regular control flow.

dilap 10y ago

I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. There's a whole lot of space between "include useful context in errors" and "exceptions". (And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.)

throwaw199ay 10y ago
> I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces. As opposed to panics? Checked exceptions don't blow up in your face, you have to handle them. Nil errors and type errors might yet these also happen to Go. I see no difference with Java here. Go isn't better when it comes to error handling, in fact Go is extremely tedious when it comes to error handling. > (And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.) So Go has both(unchecked exceptions and errors as "value"), how does it make things better? it doesn't. If it did, the blog wouldn't be talking about people "handling errors the wrong way".
- dilap 10y ago
  I've found it helpful to distinguish between errors that are program bugs and errors that are conditions of the outside world (network errors, invalid data, etc). I think it depends somewhat on the kind of software you're writing. Being very careful with errors is quite handy for a long-running server processes; maybe (maybe!) not so worth it for a program that starts and stops within the attention span of a single user.
  - pvg 10y ago
    errors that are program bugs and errors that are conditions of the outside world That also happens to be the intended distinction between Java's checked and unchecked exceptions.
- hnbro 10y ago
  > you have to handle them the definition of "handle" widely varies, to the point of making the exercise near meaningless.