Hacker News Reader

Hacker News

Comment by scarface74 | Hacker News Reader

Parent Full thread

scarface74

That’s only true if the developer of the class module let the entire stack trace get through to the consumer.

In C# it’s the difference between...

try

{

....

}catch(Exception e)

{

//Do stuff

   throw new MyCustomException(“Something Bad happened”);

}

And

try

{

....

}catch(Exception e)

{

  //do stuff

   throw;

}

View on HN

Erh, exception types should include an inner exception parameter, for the generic one they wrap. So neither of your two examples are all that great.

Why would I wrap an exception if I don’t plan to have special handling? If it is exception that I didn’t throw because of a business reason, why not just throw the original exception?

If you don't have any special handling, then why are you catching it at all?

That was the "//Do stuff" part, you may want to do some cleanup (in C# usually handled by a finally block or a "using" block), send a custom notification, logging (usually I would just let the client handle logging), etc.

In what case would you ever want the second example?

usually you may catch a general exception and throw another one that's caught up the call stack. In this case i think it may be useful for logging additional causes that are not going to be obvious with just the stacktrace(?)

Always. If you can't resolve the exception and continue processing normally, you should never discard the exception you caught and create a new one of your own. If you must create one of your own, include the one you caught for the additional context.

It's pretty frustrating when you're debugging someone else's code and their error handling just throws away all of the useful information and replaces it with a generic "Something broke" kind of message.

Reply on news.ycombinator.com