5 ms·

Exception filters aren't pointless. They preserve the stacktrace, meaning the debugger will break at the original throw and not the throw; in your catch (I'm o

• Pxtl 12y ago
  Throw in a catch block with no exception argument preserves stack-trace. That is catch(Exception ex) {throw;} Rethrows without meddling with ex.
  • Locke1689 12y ago
    Throw in a catch block with no exception argument preserves stack-trace. No it doesn't. If you then let that exception fall out as unhandled, the stack trace will be centered on the second throw, not on the original.
    • ColinDabritz 12y ago
      This case is confusing and a lot of people miss the subtle difference. In one case you try { Throws(); } catch(Exception ex) { DoHandling(); throw ex; } // BAD! This one does lose the initial site of the first exception, and throws it as a new exception at this location, centering the stack trace on this line. This is what you want to do: try { Throws(); } catch { DoHandling(); throw; } Notice you do not name, or capture the exception. This causes your handling to execute, but crucially it re-throws the original exception untouched, with the original stack trace, centering on the original exception thrown location. So you can easily lose that information if you re-throw naively. Good code tools should yell at you for doing this most of the time. Note in some cases you want to add information, so you can throw a new exception with new information, but set the InnerException property to the original causing exception. See http://msdn.microsoft.com/en-us/library/system.exception.innerexception.aspx http://msdn.microsoft.com/en-us/library/system.exception.inn...
      • toxik 12y ago
        I thought that was called try...finally
        • louthy 12y ago
          No, finally is always executed. The catch handler only executes when there's an exception.
        • ColinDabritz 12y ago
          Yes, as noted, it's a three part structure: try { MayThrowException(); } catch(MyExceptionType ex) { HandleIfException(ex); } finally { AlwaysRunCleanupRegardless(); }
      • Locke1689 12y ago
        This case is confusing and both you and the documentation are wrong. :) You're confusing the Exception.StackTrace with the actual CLR stack trace. The minute you catch an exception in the CLR the accurate trace is destroyed. This is pathological for crash dumps, where it's imperative that you have an accurate trace for debugging. If you don't believe me, go into VS and do the following. 1. Throw an exception. 2. Make sure that exception is not listed in exceptions to break on. 3. Catch and rethrow that exception using "throw;". 4. Let that exception filter out of the program unhandled. 5. Run in debugger. Notice where your stack trace is centered on -- the "throw;" call.
        • Pxtl 12y ago
          ... then fix the "throw;" call, don't bolt on a language feature to work around the fact that "throw;" mucks with the stack trace when it's not supposed to do that.
          • Locke1689 12y ago
            CLR semantics are frozen as far as C# is concerned.
        • ColinDabritz 12y ago
    • taspeotis 12y ago
      I think it depends on what you think "preserves" means. See here [1]: If the exception was rethrown in a method that is different than the method where it was originally thrown, the stack trace contains both the location in the method where the exception was originally thrown, and the location in the method where the exception was rethrown Putting aside same method/different method, the original stack trace is preserved, but StackTrace is augmented with the location the exception was rethrown. There's also a code analysis warning for misuses of throw that uses "preserve" in its title [2]. It says in your profile that you work on Roslyn and I imagine you're familiar with how the exception syntax works with the CLR, so maybe you know something I don't know. [1] http://msdn.microsoft.com/en-us/library/system.exception.stacktrace.aspx http://msdn.microsoft.com/en-us/library/system.exception.sta... [2] http://msdn.microsoft.com/en-us/library/ms182363.aspx http://msdn.microsoft.com/en-us/library/ms182363.aspx
      • Locke1689 12y ago
        It says in your profile that you work on Roslyn and I imagine you're familiar with how the exception syntax works with the CLR, so maybe you know something I don't know. I do, actually. :) See https://news.ycombinator.com/item?id=7542701 https://news.ycombinator.com/item?id=7542701.