Hacker News Reader

Comment by jansommer | Hacker News Reader

Excellent article! Something I've been wanting to write myself for years. Love the first example: try ... catch(ex), log(ex). I've seen numerous developers do this and it's always unnecessary unless you can't catch exceptions globally. Just log all uncaught exceptions in something like Sentry, or a file for that matter, via a global exception handler. It's not about eliminating all possible exceptions, it's to avoid writing a bunch of boilerplate, since every line of code could potentially fail at some point. In the rare cases where some additional context is needed besides what is always added such as the current user, then of course, log away, but write a long comment about why the exception is caught just to be logged.

View on HN

Catching exceptions higher up the stack changes the control flow of a program.

What? Perhaps in some programming languages, but catching exceptions globally in C# works just fine.

Sorry, maybe my wording was too abstract. What I wanted to say: if you remove a catch statement in the middle of the function, then all the code after the catch statement will not be executed if an exception is thrown.

I think the abstract stuff you're talking about is caught exceptions. I'm talking about catching exceptions where the only purpose is logging:

> Just log all uncaught exceptions in something like Sentry, or a file for that matter, via a global exception handler.

Maybe I misunderstand you, but the exception in the OP's example was definitely caught and not rethrown. That's often unavoidable if you want to recover and continue from the exception but nevertheless want to document that there was an exception. Same happens if the exception happened in a worker thread.

(And in before "just swallow it" - nope. I've frequently found bugs by monitoring non-fatal exceptions).

I agree though that catching, logging and then immediately rethrowing exceptions is redundant.

> What? Perhaps in some programming languages, but catching exceptions globally in C# works just fine.

I think what sesm means (as do I) is this situation:

  try { a(); }
  catch (ex) { log_warn(ex); }
  return b();

Right now, the function will continue executing and return a value even if an exception occurred, which sometimes is desirable. If you removed the catch block, nothing after a() will be executed.

That code is never acceptable. Don't catch all exceptions just to log and continue. That's like Visual Basic's On Error Resume Next sprinkled with logging! Now, you could instead catch a specific exception, a caught exception, log it, and write a very detailed comment on why you're only logging and not rethrowing, so the reviewer doesn't have to ask.

Ah, I see what you mean. Yes, if it's about recovering from a particular error, that would be for specific exceptions.

There are some cases where you basically have to make your own top-level error handling - for example in (java) worker threads. An uncaught exception would either terminate the thread or would be swallowed without showing up anywhere.

I think the flamewar algo is preventing me from replying to your message xg15, but yes, it totally makes sense to have a global error handler on threads. I think that though the original article sounds like it is never okay, I don't imagine the author is against corner cases such as global error handlers in web frameworks, threads, browsers and so on. I just wish developers would refraign from writing try catch 80% of the time, because it pretty much always boils down to only a logging call and perhaps a generic error response that the framework would take care of anyway (at least in ASP.NET).

Reply on news.ycombinator.com