Hacker News Reader

Comment by sesm | Hacker News Reader

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.

View on HN

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.

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).

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.

Reply on news.ycombinator.com