Note that there are some explanatory texts on larger screens.

plurals
  1. PODisplaying exception debug information to users
    primarykey
    data
    text
    <p>I'm currently working on adding exceptions and exception handling to my OSS application. Exceptions have been the general idea from the start, but I wanted to find a good exception framework and in all honesty, understand C++ exception handling conventions and idioms a bit better before starting to use them. I have a lot of experience with C#/.Net, Python and other languages that use exceptions. I'm no stranger to the idea (but far from a master). </p> <p>In C# and Python, when an unhandled exception occurs, the user gets a nice stack trace and in general a lot of <strike>very useful</strike> priceless debugging information. If you're working on an OSS application, having users paste that info into issue reports is... well let's just say I'm finding it difficult to live without that. For this C++ project, I get "The application crashed", or from more informed users, "I did X, Y and Z, and then it crashed". But I want that debugging information too!</p> <p>I've already (and with great difficulty) made my peace with the fact that I'll never see a cross-platform and cross-compiler way of getting a C++ exception stack trace, but I know I can get the function name and other relevant information.</p> <p>And now I want that for my unhandled exceptions. I'm using <a href="http://www.boost.org/doc/libs/1_41_0/libs/exception/doc/boost-exception.html" rel="noreferrer">boost::exception</a>, and they have this very nice <a href="http://www.boost.org/doc/libs/1_41_0/libs/exception/doc/diagnostic_information.html" rel="noreferrer">diagnostic_information</a> thingamajig that can print out the (unmangled) function name, file, line and most importantly, other exception specific information the programmer added to that exception.</p> <p>Naturally, I'll be handling exceptions inside the code whenever I can, but I'm not that naive to think I won't let a couple slip through (unintentionally, of course).</p> <p>So what I want to do is wrap my main entry point inside a <code>try</code> block with a <code>catch</code> that creates a special dialog that informs the user that an error has occurred in the application, with more detailed information presented when the user clicks "More" or "Debug info" or whatever. This would contain the string from diagnostic_information. I could then instruct the users to paste this information into issue reports. </p> <p>But a nagging gut feeling is telling me that wrapping everything in a try block is a really bad idea. Is what I'm about to do stupid? If it is (and even if it's not), what's a better way to achieve what I want?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload