Actually, exception rethrowing is a real thing - at least in Java. You may not always want to handle the exception at the absolute lowest level, so sometimes you will instead "bubble" the exception up the callstack. This in turn can help with centralizing exception handling, separation of concerns, and making your application more modular.
It seems counter-intuitive but it's actually legit, again at least in Java. lol
Rethrowing caught exception in C# is just throw;, not throw ex;. This will delete old stack trace, which is very punishable if someone debugs your code later and you're still around.
An exception will bubble up the stack until it enters a catch block that can handle it, and you may need additional logic to decide if you are finished, or it needs to go further up. (you may also intercept it just to add more data, or log it)
throw; allows you send the original exception further up, but throw ex; behaves the same as throwing a new Exception object, and therefore has a new trace. The throw statement doesn’t query any properties on the exception argument AFAIK, so it has no idea this exception has been previously thrown, but the IDE is smart enough to know you almost certainly don’t want to do this.
throw ex; treats ex as a new exception, so, it starts a new stack trace for it from itself and deletes stack trace that was saved in ex.StackTrace. On the other hand, throw; takes already present exception in the scope and throws it without modifying the stack trace, preserving the original method that threw ex in the stack trace.
I feel like I wrote the same thing twice. I'm a bit bad with explaining stuff, feel free to ask more specific questions if you still don't understand the difference.
So you are saying that the following code will keep throwing e but if I used throw e; it would basically be the same except for the stack trace that would be missing the important root cause ?!
try {
} catch (WhateverException e) {
// stuff, or nothing, or whatever
throw;
}
Depending on the language it either does nothing and just adds code bloat or (and this would be much worse) it will catch any exception that can be implicitly cast to type Exception and throw it as type Exception. So the next higher scope would not be able to catch e.g. a RuntimeException or w.e. to handle appropriately. It could only catch a regular Exception even if the original error was a more detailed type.
It's C# so it's just rethrowing the original exception.
It might also be messing with the stack trace though which can be a bit frustrating for future debugging. But that's only a vague recollection of something I read in the past so I could be wrong
Correct me if I'm wrong, but this will actually cut the stack trace and then start another one from your try-catch block, which is an evil thing to do towards those who will actually read your stack traces. To preserve the stack trace you do throw;, not throw ex;, and I'm assuming IDE is underlining that statement exactly for this reason.
If you're just going to throw it again, why bother catching it?
Actually, exception rethrowing is a real thing - at least in Java. You may not always want to handle the exception at the absolute lowest level, so sometimes you will instead "bubble" the exception up the callstack. This in turn can help with centralizing exception handling, separation of concerns, and making your application more modular.
It seems counter-intuitive but it's actually legit, again at least in Java. lol
Rethrowing caught exception in C# is just
throw;, notthrow ex;. This will delete old stack trace, which is very punishable if someone debugs your code later and you're still around.I am a somewhat new C# developer (2 years). Could you explain more about this?
An exception will bubble up the stack until it enters a
catchblock that can handle it, and you may need additional logic to decide if you are finished, or it needs to go further up. (you may also intercept it just to add more data, or log it)throw;allows you send the original exception further up, butthrow ex;behaves the same as throwing a new Exception object, and therefore has a new trace. The throw statement doesn’t query any properties on the exception argument AFAIK, so it has no idea this exception has been previously thrown, but the IDE is smart enough to know you almost certainly don’t want to do this.throw ex;treatsexas a new exception, so, it starts a new stack trace for it from itself and deletes stack trace that was saved inex.StackTrace. On the other hand,throw;takes already present exception in the scope and throws it without modifying the stack trace, preserving the original method that threwexin the stack trace.I feel like I wrote the same thing twice. I'm a bit bad with explaining stuff, feel free to ask more specific questions if you still don't understand the difference.
Seen this so many times, i weep for humanity
I'm offended that you'd put my code on the internet.
“I’ll come back to this”
Lol what’s wrong with this if the parent function catches it
If this is C# (and it looks like it is), this leads to you losing the original stack trace up until this point.
The correct way to do this in C# is to just
throw;after you're done with whatever you wanted to do in thecatch.wait what ?
So you are saying that the following code will keep throwing
ebut if I usedthrow e;it would basically be the same except for the stack trace that would be missing the important root cause ?!Exactly. Aside from deleting your already built stack trace, as a bonus you'll get another stack trace building call, enjoy wasted CPU cycles.
Depending on the language it either does nothing and just adds code bloat or (and this would be much worse) it will catch any exception that can be implicitly cast to type Exception and throw it as type Exception. So the next higher scope would not be able to catch e.g. a RuntimeException or w.e. to handle appropriately. It could only catch a regular Exception even if the original error was a more detailed type.
It's C# so it's just rethrowing the original exception.
It might also be messing with the stack trace though which can be a bit frustrating for future debugging. But that's only a vague recollection of something I read in the past so I could be wrong
Throwing exceptions are very costly due to the stack trace, so building the stack trace twice will cause a big performance hit
Correct me if I'm wrong, but this will actually cut the stack trace and then start another one from your try-catch block, which is an evil thing to do towards those who will actually read your stack traces. To preserve the stack trace you do
throw;, notthrow ex;, and I'm assuming IDE is underlining that statement exactly for this reason.Yes, hence why I mentioned it collects the stack trace twice.
It's more than just more difficult for debugging
The
catchis useless if it's just throwing the exception anywayThe catch is mandatory...
You don't catch it if that's the case
You could just not catch it and it'll get thrown up the stack anyway.
Then the parent function would catch the original exception if it was never caught in the first place. All this does is bork the stacktrace.
This can't compile, can it? Only a madman commits code which doesn't compile.
Why wouldn't it? It's syntactically valid C#, with the added bonus of destroying the stack trace
Who needs stack traces anyway? Just search all of your code on the word throw until you have the right one