Hacker News Reader

Comment by jameshush | Hacker News Reader

This post is close to 20 years old but it's still how I handle errors: https://www.joelonsoftware.com/2003/10/13/13/

From the article:

    People have asked why I don’t like programming with 
    exceptions. In both Java and C++, my policy is:

    1. Never throw an exception of my own
    2. Always catch any possible exception that might be thrown by a library I’m using on the same line as it is thrown and deal with it immediately.

I've been coding this way for ~10 years now and it's made things a lot easier for me. If the user should know about the error, let them know about it, if it should be hidden from the user, I'll track it in something like Sentry or Datadog and send out an alert for whoever's on call.

View on HN

I have to say I hate that. I do not miss the "Is this actually failing?" debate I get every time I write C.

Joel complains about exceptions being invisible but how is returning errors any better?

If a function returns 0 has it failed?

If it has failed why? Has it lost connection? No results? A generic no? If another function from the same library returns a 0 is that also an error or is error reporting inconsistent?

It's impossible to know what is being communicated to the point I don't even know its an error.

> catch any possible exception that might be thrown by a library I’m using on the same line as it is thrown and deal with it immediately.

What does "deal with it immediately" mean, that exceptions don't already do?

Edit: to explain a little more: when an error is returned from a procedure, control flow can do one of exactly two things:

1. Handle it in some specific way (retry the operation that failed, proceed with a default value for an optional operation, try to modify input parameters and run again, ignore completely, etc)

2. Return the error to an upper-level caller (calling function, OS).

You may of course add some optional extras (log the error, clean up any resources), but the above are the only 2 options for how control flow can continue.

Now, if you can do 1: perfect, do it, that is the best case scenario.

But, there will always be cases where you can't handle this error, and your only option is 2. Now, 2 can be achieved by many mechanisms: exit(ERR_CODE) to return to OS, automatic exception propagation, manual error return value propagation, set some error flag and return, etc. But they are all ultimately equivalent, and each have their pros and cons.

Exceptions don't deal with something, they cancel everything else that was scheduled to run after.

If you catch an exception immediately (in the calling function) then that's immediate handling. But then there wasn't really a point in using an exception vs returning an error code.

Exceptions mainly allow you to be lazy, and work well with systems that have some introspection how to cleanup themselves: Garbage collection, RAII, OS processes...

I'm not convinced that relying on these systems scales well to complex applications. And maybe I'm doing something wrong, but I don't think manual error handling is a big hassle if you put some thought in structuring the system.

My question was "what does it mean to to you (or to Joel Spolsky, since it's his words originally)" to "deal with an error immediately"? Do you see some third option in addition to my 1 and 2?

Otherwise, whether you write:

  {
    auto x = new int[100];
    int err = foo(x);
    if(err) {
      delete[] x;
      return err;
    }
    //do something with x
    delete[] x; 
    return 0;
  }

or you write

  {
    auto x = std::unique_ptr<int>(new int[100]);
    foo(x);  
    //do something with x
  }

I don't see any significant difference. The exception case is shorter (less code to review), while the manual error return code is more explicit (easier to review the code).

> I don't see any significant difference.

Because this is a toy example.

In a real system, you avoid allocating / deallocating the buffers right before and after you work on them, to begin with.

You are not answering my question. The fact that x is a buffer is irrelevant. Here, I'll rephrase:

Otherwise, whether you write:

  {
    auto x = fopen("someFile");
    int err = foo(x);
    if(err) {
      fclose(x);
      return err;
    }
    //do something with x
    fclose(x); 
    return 0;
  }

or you write

  {
    auto x = std::ifstream("someFile.txt");
    foo(x);  
    //do something with x
  }

What is the fundamental difference?

I'm not sure what obvious or not-so-obvious observation you want me to state, but in my point of view there is no difference relevant to this discussion; both is uninteresting and bad code that you want to avoid writing in a larger system.

It doesn't change much whether this is a buffer or any other kind of resource. As your system grows more structure, the handling of resources (including errors) is moving more and more towards centralized subsystems. You want to avoid complicated fallible and _repetitive_ logic inside random "application" code. In application code, you don't want to just open files, incurring all sorts of non-deterministic latencies, blocking the current thread of execution. What you do instead is, you move to an event based system, where your "application modules" are completely contained in a shell of "platform code".

Note that both your examples contain really boring _repetitive_ code, whether visibly in the source, or only in the assembly generated by RAII mechanism. This is _bad_ as soon as you have multiple of these chunks of code.

Think web applications. Do you accept() a socket from within any random request handler? Does any request handler read() from the socket to parse the request data? No, all that happens in a driver that just notifies the individual request handlers when more work is coming. Consequently, the only places where errors from accept() or read() need to be handled are at central locations within the framework. This requires some structure, for example your web request handler has to be registered with the web framework, like framework.register_handle("POST", "/foo", handler). Or similar, I'm actually not a web person.

In the same way, you don't fopen() files in any random place in a 100 KLOC codebase. Instead you have abstractions for asset loading, media playback, savefile storage, ... whatever and _ideally_ all those come back to probably some kind of caching layer, maybe an async I/O worker pool, and finally a single line of fopen() (or open()) in your entire codebase.

Note that for this to work, you have to change your general approach to things. You can't expect to write script-like code anymore that does "save file now" or similar. What you do instead is, you push a job to some subsystem, and when the job is done you will be notified later so you can complete the necessary tasks. It's all event handling.

My philosophy has always been: Clearly separate the input from the result from the error, using different features of the language for each. Pass input variables only as arguments, return only the "result" of the function, and throw errors. Take the classic (and simplistic) divide function, in pseudocode. There are a number of ways you can do it, and I'm not listing them all:

    divide(numerator, denominator) returns quotient, throws error

    divide(in numerator, in denominator, out quotient) throws error

    divide(in numerator, in denominator, out quotient) returns error

    divide(in numerator, in denominator, out quotient, out error)

    divide(numerator, denominator) returns tuple(quotient, error)

I've always considered the first one more expressive, more usable by the caller (e.g. you can pass the result of the function directly to the next function), and the least confusing. The second one is -meh-.. I'm just not a big fan of input and output arguments. You have a return value, why not use it? The last three are particularly bad, because the caller must remember to check the error value manually (unless your compiler can remind you).

> Exceptions mainly allow you to be lazy

This is not quite right. Exceptions allow you to be safe. Think of it like a factory that's practicing Toyota design -- any worker can pull a alarm that stops the entire production line if there's a critical safety issue.

For code, this alarm pull is the exception. And when you pull it, everything restarts from scratch so it must be in a good state on recovery. Sometimes if a component fails, there is no clear and logical way to recover from the intermediate state (perhaps there are unsafe or insecure assumptions that would need to be made to keep going), so it's better to give up.

I agree about the idea of pulling the alarm handle when some state goes wrong. However the problem is the notion that the problem is in the code (after all, exceptions cancel the scheduled code). No, the problem is in an individual object / data structure, and as I said simply cancelling all the stuff is fine for a script (or a web request handler if you want) but I don't think that's how you build complex, reliable and deterministically performing systems.

The claim is not that the problem is in the code. The problem is something like "database is unreachable" and yes, this is exactly how you build complex and extremely reliable systems -- it's the underpinning of how Erlang systems can have uptimes in the years. Fundamentally it's also how kuberbetes works. One of the containers has pulled it's alarm, so the pod "supervisor" restarts it.

> The claim is not that the problem is in the code.

But exceptions act very much like the problem was the code. They cancel the following code in any function on the stack, which in general is unrelated to the error in the state where the exception originated.

Another problem is that the exception originates from code instead of the object that is in a bad state. In other words, you need to step on a landmine to even notice that the object was already bad. It would make much much more sense if the "exception" was stored with the object/handle instead of propagated up an unrelated call stack, a single time.

With Erlang exceptions, the model might fit better I don't know. I looked at it many years ago but never used it.

Just for completeness, “condition” systems offer a third option, where a condition can be handled by a caller without fully unwinding the stack:

https://gigamonkeys.com/book/beyond-exception-handling-condi...

How do you deal with something 15 layers deep that has an error? Bubble up the error through all those function returns (e.g. Go style)?

If needs be. But ideally you get to a point where an error turns into a business rule. SQL "no rows found" error? Becomes a business "record not found" error, which is turned into a HTTP 404 on an HTTP API edge.

Don't have call stacks 15 layers deep. It's a problem in itself when the only choice you have is either ignoring the error or cancelling 15 layers of god-knows-what-code-must-still-run.

Sounds quite ineffective.

Just throw an appropriate exception type and deal with them in a single spot.

What happens if you forget to catch an exception? System default error measage printed out?

Reply on news.ycombinator.com