5 ms·

Explicit error handling is a design choice, not a language defect. If you don't like it, you don't have to use the language. Many people choose to use explicit

Explicit error handling is a design choice, not a language defect. If you don't like it, you don't have to use the language. Many people choose to use explicit error handling even in languages that support exceptions. Knowing that every function call returns a value that is handled locally makes it a lot easier to reason about your program and debug it. Also, this 75% number sounds made up out of thin air. If your program is doing something non-trivial, it should have far more code doing work than checking errors.

AnimalMuppet 3y ago
I recall reading back in the 1970s or 80s that error checking and handling took 80% of the lines of code of production-ready software. That would be pure procedural code, not exceptions, not FP style. (And that's all I've got - one hearsay-level report from decades ago.) I have not, ever, seen any numbers for exception style or FP style. My perception is that their numbers might be lower, but I have no evidence, and I am not dogmatic about my guess.
- fasterik 3y ago
  I can't really imagine 80% error handling for the whole codebase unless literally all of your functions look like this: int foo(Data *data) { int error = do_some_io_request(data); if (error) log_error(error, "Request failed"); return error; } For propagating errors up the stack, the ratio is only 50%: int error = foo(data); if (error) return error; For the rest of your code, I guess it's domain specific. But most projects should have a significant amount of the codebase doing things with data in memory that can't fail.
  - AnimalMuppet 3y ago
    A lot of code looks like this: int handle = open(file, S_IREAD); if (handle == -1) return false; int size; if (read(handle, &size, sizeof(size)) != sizeof(size)) { close(handle); return false; } char *buffer = malloc(size); if (buffer == null) { close(handle); return false; } if (read(handle, buffer, size) != size) { close(handle); free(buffer); return false; } And so on, with the number of things you have to clean up growing as you go further down the function.
LispSporks22 3y ago
I asked a Go programmer how much of the code base was Go error handling boilerplate. He measured it and said 75% I suppose it varies from code base to code base. There’s no denying it’s high though. > handled locally Except in practice, you don’t. You just keep returning the error up the call stack until something handles it at the top, probably by trying again or more likely just logging it.

AnimalMuppet 3y ago

I recall reading back in the 1970s or 80s that error checking and handling took 80% of the lines of code of production-ready software. That would be pure procedural code, not exceptions, not FP style. (And that's all I've got - one hearsay-level report from decades ago.) I have not, ever, seen any numbers for exception style or FP style. My perception is that their numbers might be lower, but I have no evidence, and I am not dogmatic about my guess.

fasterik 3y ago
I can't really imagine 80% error handling for the whole codebase unless literally all of your functions look like this: int foo(Data *data) { int error = do_some_io_request(data); if (error) log_error(error, "Request failed"); return error; } For propagating errors up the stack, the ratio is only 50%: int error = foo(data); if (error) return error; For the rest of your code, I guess it's domain specific. But most projects should have a significant amount of the codebase doing things with data in memory that can't fail.
- AnimalMuppet 3y ago
  A lot of code looks like this: int handle = open(file, S_IREAD); if (handle == -1) return false; int size; if (read(handle, &size, sizeof(size)) != sizeof(size)) { close(handle); return false; } char *buffer = malloc(size); if (buffer == null) { close(handle); return false; } if (read(handle, buffer, size) != size) { close(handle); free(buffer); return false; } And so on, with the number of things you have to clean up growing as you go further down the function.

LispSporks22 3y ago

I asked a Go programmer how much of the code base was Go error handling boilerplate. He measured it and said 75% I suppose it varies from code base to code base. There’s no denying it’s high though. > handled locally Except in practice, you don’t. You just keep returning the error up the call stack until something handles it at the top, probably by trying again or more likely just logging it.