It's funny how alcohol actually makes you remember all the crazy shit you had to deal with.

As when I was a junior c# programmer at an ERP shop.

I was new, naive and full of energy.

I used to dive deep into the code base, and one of the things I noticed but didn't pay too much attention was.

Error stacks were usually meaningless.

And why was that?

First, well it was c#.

Second, the guys use to do this.

try {
ThrowingFunction();
} catch (Exception e ) {
throw e;
}

PS: I'm not doing c# anymore, that was 10 years ago. So syntax might be a bit off.

Did you mean stack trace?

And with such error handling, yes, stack trace loose a lot of value.

But in well structured code stack traces are often very helpful in c#.

@Voxera yes, as stated I was a bit drunk.
And the reason stack traces were meaningless was because they were creating new errors.

It might have been `throw new Error(e.messages)` instead of `throw e`

@galileopy Here's a tip:

If you need to "re-throw" an exception but from a different code block and at a different time, use this

ExceptionDispatchInfo.Capture(exceptionObject).Throw();

this will throw the same exception and with proper stack trace reflecting where the exception was originally thrown and where it was re-thrown too.

More info:

https://docs.microsoft.com/en-us/...

@MrCSharp or just do not rethrow.

They were doing that on almost every try-catch block. Wich I found out later that's a terrible code smell.

@MrCSharp better yet, do not rethrow unless you add some useful information, like local state to help trach the cause, but always include the original error.

I do this sometimes in methods that are called multiple times with different data and where stacktrace are useless anyway as there only exist one path and the state is the important part.

@Voxera ofc the problem was that the practice across the company was to hide the original error.

Debugging was a pain.

@Voxera I'd take that one step further and say don't even put a try catch block unless you Will do something with the fact the code has thrown an exception.

Catching and then rethrowing without additional processing of the error or an attempt to correct it is meaningless.

As for my example of rethrowing using that utility, it can be helpful in a few situations and it heavily depends on how the code is structured. Like everything else in coding the answer is: it depends.

@MrCSharp in my case we use it when the original error comes from code nit under our control and where we for example need the input to the method that are throwing an exception for tracking the error.

Fo example where we have failed to recreate the error and need more.

Also in my script engine as stack trace there is often 100 levels deep recursing through the same set of methods traversing the ast tree.

In that case current state or input is the most import information to identify which instruction it was processing with what data, not the line or stack trace ;)

But thats also a very odd edge case most will never encounter.