[nicklecompte]

> Writing code with the occasional try/catch block isn't too different from writing C and not checking error conditions

I think a critical difference is that in C the program is more liable to simply crash if errors aren't correctly handled, whereas in Java/Python/etc the program can just log a stack trace and keep on truckin', even if the bug is actually quite severe. In some cases a crash is preferable - e.g. if something goes wrong in a text editor while saving data, it's a lot better for the user if the program crashes versus the alternative where the editor runs as normal but saving doesn't work. Crashes in C also bring more urgency for developers to actually fix the bug compared to a try/catch in Python that simply buries it "until I get a chance to debug it properly." (But crashing also leads to a lot of frustration when the error wasn't that important and the C program should have just kept going.)

[kaba0]

So it is worse, therefore it is better?

Exceptions are exceptionally good at error handling - they always do the correct default (bubbling up if not handled, bringing a stacktrace with them, and by default they auto-unwrap the correct return value, not making the actual business logic hard to decipher), plus they make error handling possible on as wide scope as needed (try block vs a single return value).

I absolutely fail to see how a “random” C program would fair better, I’m sure the errno state is not checked at every line, as it is a trivial human error to leave that out. You can’t forget exceptions, which is how it should be!

If anything, that java/python text editor will catch every exception at the top level, save the file and exit with an error message and it will be the C program that either randomly crashes, or ignores some exceptional state.

[acuozzo]

> I’m sure the errno state is not checked at every line, as it is a trivial human error to leave that out

While writing code it's trivial to ask yourself if the next statement will include a call to a function which is not defined within a compilation unit under your control.

If it will, then you lookup documentation for that function to determine what it expects and how it can fail. Most of my functions which interact with such functions look like long sequences of this:

  /* close the file */
  ret = -1;

  do {
    errno = 0;
    ret = close(fildes);
  } while (0 != ret && EINTR == errno);

  if (0 != ret) {
    perror("Error");
    goto off_ramp;
  }

I've caused plenty of bugs in my career, but I can say with confidence that 0 of them had to do with ignoring/skipping proper error handling. You have to do so intentionally.

[tored]

Many years ago I started to dislike exception handling, probably because working in large software projects with many exceptions floating around.

Then a few years ago I started to write code in a primitive language without exception handling. I miss exceptions now.

[nicklecompte]

> Converse curiously; don't cross-examine. Edit out swipes.

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize.

> Eschew flamebait. Avoid generic tangents.

In particular you seem to be responding to a strawman, since nowhere did I say C error handling was better than structured exceptions. The parent asked what was functionally different between laziness around checking error codes versus laziness around try/catching.

[kaba0]

You wrote:

> in C the program is more liable to simply crash

I simply disagree with this statement, as silent failure is also very common in case of C, which is probably the worst option. (Especially that it may cause memory safety issues, that may not even materialize until much later).

No need to take my comment that seriously though, I had no bad intention whatsoever.