Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Ale Contenti and Louis Lafreniere: Understanding Exceptions and When/How to Handle Them

Download

Right click “Save as…”

  • MP4 (iPhone, Android)
  • High Quality MP4 (iPad, PC, Xbox)
  • Mid Quality MP4 (Windows Phone, HTML5, iPhone)
  • Mid Quality WMV (Lo-band, Mobile)
  • MP3 (Audio only)
  • WMV (WMV Video)
Sometimes, things go wrong when code executes. You can't predict when this will happen or even why, but you can write code to handle exceptional problems. If you're lucky, the problem will carry with it a bunch of useful information that you can use, at runtime, to handle the specific error. These exceptional information structures are called structured exceptions; blobs of bad news carrying useful and specific information that you can use to find your way out of the exceptional rabbit hole. Of course, with useful data packaged up in an exception you can more easily debug to find root causes, which is much harder to do with, say, error codes...

What is a structured exception, exactly? How should you handle exceptions that you don't assume will arise during the execution of your code? What are the correct patterns of exception handling that you can safely rely on? What does the C++ compiler have to do with exception code patterns?

Come along for ride into the deep and murky world of exceptions with some folks that truly understand them at the most fundamental levels.

Ale Contenti is a senior development lead in the C++ base class libraries team. Louis Lafreniere is a principal software developer in the C++ compiler group. Here, Ale and Louis teach us about exceptions and handling them (and when not to handle them). I love talking to the VC++ People. They live on the metal and really understand the fascinating intracacies of our platform.

Enjoy this latest Going Deep episode.

Tags:

Follow the Discussion

  • yes, yes! another interview with the vc++ team! i just can't wait to see the thing i've read on herb sutter's blog recently: "The thing we can't talk about but that has something to do with MFC". I suppose it's more than MFC 9.. i hope..
    anyway, thanks a lot, Charles, for these going deep videos - especially the ones from c++ land.
  • i really liked the comparison between throw and beep Smiley and unmanaged and managed world

    very nice interview, thanks Charles!
  • CharlesCharles Welcome Change

    Glad you enjoyed this! You can expect to see some more very interesting videos from Microsoft's C++ World... Wink

    C

  • Ok, I had to stop the video just now (roughly the 30 minute mark) where you are discussing the states in a function and how you keep track of the state. (i.e. -1, 0, 1, 2, 1, 0, -1).

    One question, if some nut wrote a function with more states than your long integer (assuming you are using a long int) can handle, would it crash ? and if so how bad.

    Very kewl and Charles can we get more videos to discuss low level topics such as this.

    back to the video I go  !  Good work guys...


  • Yes the EH state is stored as 32 bits on Win32.  You need a new state for each new C++ object, and for each new try block you enter.  If you overflowed that state, things would go very wrong.

    However, there are many other limits you would hit before hitting this one.  The compiler has limits on how big a function can be, how many objects it can have, how many curlies can be opened, etc. 

    Even if you could compile your program, you would run out of stack space to store all these objects, and your program wouldn't fit in memory (a state update is more then a byte). Smiley

    -- Louis Lafreniere

  • Hello

    Re: the comment from mwirth

    > "The thing we can't talk about but that has something to do with MFC". I suppose it's more than MFC 9.. i hope.. 

    We do have plans for a Channel 9 video on the upcoming MFC extensions – all going well look for these towards the end of this year.

    FYI: for a sneak preview I should mention that Ale is presenting at TechEd Europe: Developer in Barcelona on the MFC extensions in November - information below.

    Thanks

    Damien Watkins

    Visual C++

    --

    Title/Code: TLA404 MFC Updates for Visual Studio 2008 and Beyond   

    Presenter: Ale Contenti   

    Abstract: This session will demonstrate the new features added to MFC in Visual Studio 2008, including support for Vista Common Dialogs, Vista Common Controls, the Microsoft Office 2007 Look and Feel (including support for an Office Ribbon style interface), Office and Visual Studio style Docking Toolbars and Tabbed Documents. We will also talk about our plans to evolve the MFC library for Visual C++ 10 and beyond. This is an in-depth session designed for experienced C++/MFC programmers. (C)   

  • Thanks for your reply, damien! Just reading the abstract for this talk you mentioned assures me that it's ok for me to stay with native c++ for quite a while Smiley its so great that we might be getting a usable and current framework for windows development from microsoft again. i don't really enjoy using third party UI frameworks...

    Cheers!
    Martin
  • Hello

    The preference for this general functionality to be “in the box” is a customer comment we have heard loud and clear. There will always be room for third parties to add great value in areas we cannot cover but to be truthful we should have done more over recent years and I hope you are delighted with the upcoming extensions.

    Thanks

    Damien

  • I was hoping to hear more about where the exception objects 'live' until they're caught:
    • Is some big buffer allocated into which they are placed, on a per-stack basis (in which case, who allocates it? What if I stupidly use CreateThread instead of _beginthreadex)?
    • Is the exception constructed first and copied there (or else what happens when an exception is thrown during exception object construction - when is the exception considered thrown)?
    • How big can an exception object be?
    • If I do something silly to increase the alignment of a class, is that handled?
    • How do exception frames work within exception handlers? So on.
    Great video otherwise, but it would have been nice to get further into the implementation details beyond "We have a linked list of frames at FS:0 on x86 and a table of handlers based on instruction addresses for x64". For example, a while ago I saw Brandon Bray give a great presentation on SafeSEH, which wasn't even mentioned here.

    Regards,
    James.

  • I'll try to answer your questions as best as I can:

    Is some big buffer allocated into which they are placed, on a per-stack basis (in which case, who allocates it?

    When an object is thrown by value, the compiler emits a copy constructor to copy it to the argument stack of throw().  If the catch catches by value, the object argument of the throw will then be copy constructed by the CRT to the argument stack of the catch.

    What if I stupidly use CreateThread instead of _beginthreadex)?

    Ale could probably better answer this one, but in general you should always use _beginthread or _beginthreadex when using the CRT to make sure the CRT internal data structures are properly initialized.  I don't recall that EH uses any global data structure, but I could certainly be wrong here.

    Is the exception constructed first and copied there (or else what happens when an exception is thrown during exception object construction - when is the exception considered thrown)?

    I think I've answered the first part of your question.  For the second part, the exception is considered "thrown" once the throw() has called RtlRaiseException().  So in the scenario above, if the first copy-ctor throws, the first exception had not been officially thrown yet, so the new exception takes over.  If the second copy-ctor throws (copying to the catch), the CRT will catch the exception and call terminate().

    How big can an exception object be?

    As long as it can fit on the stack I believe!  That's if you throw and/or catch by value of course. 

    If I do something silly to increase the alignment of a class, is that handled?

    Since we don't support __declspec(align) on parameters, the answer is no.

    How do exception frames work within exception handlers? So on.

    Are you asking about how we handle the case where there is a try/catch inside a catch block?  The catch handler actually shares the same EH frame/tables as the parent function.  On Win64, the handler of course have separate unwind entries, but do share the IP (instruction pointer that is Smiley ) to EH state table.


    I hope this helps!

    EH is a very broad subject and there are many facets to it which could each be a talk on its own: perf, usability and best practices, security, under the hood implementation, etc.  I think we tried to cover the most important part of each of these (it's true that we didn't touch security though), but we do need to keep these videos down to a reasonable lenght.

    -- Louis Lafreniere

  • Hi,

    about the last question on CreateThread vs. _beginthread, the C++ runtime DLL will take care of creating the PTD (per-thread-data) slot and associating it with the thread. Check the code in DLL_THREAD_ATTACH in the CRT DllMain.

    Like Louis says, it is better to use _beginthread, but CreateThread will work anyway.

    Also, during the video I mentioned Herb's book "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" (link here

    And how do you get your Watson dumps? It's pretty easy (special thx to Jason Hardester for the info):

    Go to https://winqual.microsoft.com and:

    1. Establish a company account on Winqual
    2. Sign (online click through) the WER TOU agreement
    3. Map your files using APPMAP.exe

    Ale (see you in Barcelona Smiley)

  • Thanks for the feedback.  True you would end up causing various other "things" to start breaking or even not compile.  But it would be fun to see what happens when the EH overruns ![6]

    Ale, can you post your speech after your done ?

    thanks again
  • Are you referring to the MFC talk for TechEd? We'll do something special just for Channel9!!Wink
  • tsfreakstsfreaks What? ... Where? ... No!? ... Really!? ...  Shiii
    Interesting.
  • Is there ever (vc10 perhaps?) going to be an option to have zero-cost exception handling for x86/32bit?

    There are a few places (notably games) where the overhead of the bookkeeping required for exception handling makes it a more attractive option to just disable exception handling altogether, which naturally is bad because it limits the set of tools at one's disposal.
  • The problem with adding a static EH model on x86 is that the new code wouldn't be able to interact with code compiled by a previous VC compiler, or from another compiler vendor.

    For a static EH model, you need the ability to unwind the stack 100% reliably.  The loose calling conventions defined by x86 Win32 do not make this possible.  The debugger certainly tries, but it can't do it in 100% of the cases.  We'd need to add some new rules and info to the image to allow this, but any code not following these rules couldn't be unwound.  This in my mind diminishes the value of the feature.

    For a static model to work, it needs to be defined in the ABI from the start, like it was for Win64 on IA64 and x64.

    BTW, static EH models don't quite have zero-cost.  The possibility of exceptions in an application adds new possible control flow which affects optimizations.  You could call it low-cost! [A]

    Louis Lafreniere
  • Not so hard as I considered.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.