Exception Handling in C++

[Doc Roc]

Oh my god, it's so bizarre. Take a look at these articles.
http://tinyurl.com/256bcl
By freaking Herb Sutter

http://tinyurl.com/msdn-exceptz
Related weirdness

http://codepad.org/PpbFhX7o
Example of behavior that should raise exceptions, but instead fails immediately


Sorry, I had to vent somewhere.

[Arakune]

Nice findings. What year/semester are you?


a) Exception specifications don’t participate in a function’s type.
b) Except when they do.

And hilarity...


Are the comments correct? Not quite. Gunc() may indeed throw something, and Hunc() may well throw something other than A or B! The compiler just guarantees to beat them senseless if they do… oh, and to beat your program senseless too, most of the time.

ensues.

And what exactly the output was again? I believe it was something not meant to be, on many levels.

[Doc Roc]

So yeah, basically, as far as I can tell, "Safe_iterators" are just fail-fast iterators, that guarantee an unrecoverable crash. I'm not even sure they core-dump, so they may actually be worse from a debugging standpoint than a seg.

Which is undiluted nightmare fuel.

I just finished my BA in Comp Sci, and learned.... very little in school.

[Arakune]

Oh, my senior!

What kind of black magic did you discovered in the real world?

[Thajocoth]

In all my years writing C++ code, I've never had the misfortune of writing the words "try" or "catch". Convention generally is... Make sure it doesn't need one.

if (den != 0)
{
val = num/den;
}
else
{
val = 0;
}

That right there's how you do C++ exception handling. That else block? That's where you "catch" the "exception".

Then again, I've only worked on coherent closed systems that don't have to deal with Windows. Things might be different when dealing with an open system like that.


..."Safe_iterators"...
I have never heard of these. I use something called "int i;". Often, this'll be "int i, j, k, l;" for nested iterators. Coding convention: A variable with a single letter name is either an iterator or a coordinate, depending on whether you start with i or x.

[Doc Roc]

You drop your physics major, is how.

And what do you do if the underlying data structure changes from an array to a xor linked list? or a Judy array? Or a critbit tree?

[Thajocoth]

So you're a C hacker?

No. This is just normal C++ programming. I still use all the m_, g_ variables, header files, never put more than 2 instructions on a line, ect...


I just finished my BA in Comp Sci, and learned.... very little in school.

Two things... Firstly, how do you get a BA in a Science? Secondly, after getting my BS in Comp Sci, my first employers were surprised I'd never seen STL before. What you learn is how to use stuff, not necessarily what you'll wind up using. You should be able to take a brand new language you've never seen before, and dive in. Stuff like that. General over specific.

[Doc Roc]

I'm just following best practices according to the C++ standard and what I've learned working extensively with the Boost libraries.
Most of the professionals I've talked to suggest that it takes five years to achieve an approximation of mastery when it comes to a programming language. Considering that these are people like Paul Graham, I'm inclined to accept that they might know what they're talking about. That's hardly Dive Right In.

[Thajocoth]

den != 0 ? val = num/den : val = 0;

That's the most I'd ever do on a single line. And that'd get a nice comment next to it.

[Doc Roc]

I'm not really concerned with how many statements you'd stack on a line. In fact, this is sort of a derail all together. What I want to know is what can I do to offer reliable failures for incoming iterators, not be told that I'm obviously a moron for using iterators. Just because my programming style leans more towards generics and meta-programming doesn't make it wrong.

Regarding learning languages quickly. (http://norvig.com/21-days.html)

[Pyrian]

I've worked with a lot of libraries that fail by simply returning a null value (or some such) and I've found that a lot more convenient than thrown exceptions, precisely because there are more ways to handle it (and in many cases the routine can proceed without issue). If you need a run-time explanation for the failure, though, the exception provides an easy and appropriate way to communicate that information.

Mastering languages is easy. Mastering libraries, API's, and such, is what takes months or years. Weird personal example: having had experience in Excel VBA, it was quicker for me to use Automation to write reports in Excel in LotusScript than to produce the same reports natively in Lotus Notes. :smalltongue: The fact that said reports ended up being much more portable and useful was just a side-benefit.

[Doc Roc]

Re: Null
I'd be quite delighted if this problem resolved down to merely checking for null, but it looks extremely unlikely. Information regarding run-time state and precise sourcing of the error is crucial to high assurances programming.


Mastering languages is easy. Mastering libraries, API's, and such, is what takes months or years. Weird personal example: having had experience in Excel VBA, it was quicker for me to use Automation to write reports in Excel in LotusScript than to produce the same reports natively in Lotus Notes. :smalltongue: The fact that said reports ended up being much more portable and useful was just a side-benefit.

My experience has been a slightly more grim echo of this, but I would note that in some cases, such as haskell, I have had some difficulty actually learning the language to a point where I would be comfortable suggesting that I had anything approaching fluency. Though that may be more a factor of disuse, if I am introspective.

[Thajocoth]

I'd answer the question as well, but with Pyrian's post above, it'd sound like there's an echo in here.

null is when you have nothing. If something returns null, it is saying that it does not have an answer for you... That is, something about the input was something it could not handle. So you simply check for null whenever you need to.

I wish I was writing my current game in C++... I'm stuck with mismanaged code (C#).

[Pyrian]

Information regarding run-time state and precise sourcing of the error is crucial to high assurances programming.Are you using a library or your own code? Exception handling is not difficult to duplicate. If the built-in exception handler isn't working properly, a simple parameter and set of checks should be able to accomplish the exact same task. If you're using a library which doesn't operate as advertised and you're set on high assurance, you are more-or-less fundamentally out of luck.