   C++ Exception Help
  Hello, I'm doing a presentation on C#, and I'm supposed to do 3 applications to show different features of C# vs another language. Anyways, I was reading this article:http://blogs.msdn.com/ericgu/archive/2005/01/26/360879.aspxAnd I wanted to make one on the Exception part. I'm just a little confused on what he's talking about though, because I thought C++ supported exceptions.I was just wondering if anybody could go into just slightly more detail so I have enough information to make an example with.Thanks much all!   
  The article's entire section on exceptions is nonsensical, because you use exceptions for the same thing in both languages : Exceptional things. In C#, you still use other means to report errors.   ;  Standard C++ supports exceptions. Not every program/library uses them however, return values are often found to be more pragmatic in practise. Some implementations have poor support for exceptions, they may be totally broken (e.g. some consoles) or unreasonably expensive to throw. Even simply enabling exceptions can make every function take a small performance hit (but one needs to balance this against the manual code that needs to be written to handle and propagate alternative error handling methods).The bigger compilers on most PC platforms have decent support for exceptions, though not everyone is a fan of them.   ;  It does but there is rather common idea in C++ that exceptions should be used only for truly exceptional errors. Throwing and catching exceptions is (considered) too slow for rather "normal" execution paths.Personally I don't entirely agree. Or more precisely, what "exceptional" means can vary a lot with the context. My own code doesn't normally use lots of exceptions, though, since in 99% cases a boolean success/failure is enough for me. I don't enjoy error codes much, though.In any case a C++ programmer's attitude towards exceptions is diametrically opposite to for example Python idioms (rely heavily on exceptions to the point that you shouldn't check things before, e.g if a map contains a key - just access it an catch the exception if it wasn't there).   ;  I use exceptions for exceptional cases (like errors) and as routine case, for breaking out of recursive algorithms.An example: In my kd-tree class, I have a method which takes a sphere and a functor and applies functor to every objects intersecting that sphere. (Naturally, that method recursively goes up kdtree). When I want to simply check if there is anything in kdtree that intersects the sphere, I throw exception from functor and catch it outside. Regarding performance: I do not think that exception would be significantly slower than any other break out of deep recursion, though your mileage may vary. I never benchmarked it as it is a rather rare operation in my program.[Edited by - Dmytry on May 4, 2009 5:58:10 PM];  The reason a lot of people, who are actually nothing but bad C++ programmers, don't use exceptions in C++ is because exceptions require quite some programming discipline, and if you do not follow that discipline it shows more in C++ than in other languages due to the use of manual memory management.But actually, GC doesn't solve the problem either, since it only works for memory resources, it just hides it.The real answer is RAII, the only clean way to ensure exception safety.If only all C++ programmers could follow it to the letter...The fact that exceptions are slow and incur overhead is a myth, also. They can be implemented in various ways, with different benefits. The recommended way is much faster than return codes, albeit it increases code size.I suppose exception performance has a bad reputation due to some bad implementations, such as the ones from Microsoft. The exception handling protocol for C++ that MSVC uses is still slow today, even, but that's Microsoft's choice so that it can support their crappy additional broken features.   ;Quote:Original post by rip-offStandard C++ supports exceptions. Not every program/library uses them however, return values are often found to be more pragmatic in practise. Some implementations have poor support for exceptions, they may be totally broken (e.g. some consoles) or unreasonably expensive to throw. Even simply enabling exceptions can make every function take a small performance hit (but one needs to balance this against the manual code that needs to be written to handle and propagate alternative error handling methods).The bigger compilers on most PC platforms have decent support for exceptions, though not everyone is a fan of them.So going off this, would it be better to maybe use non-standardized libraries?I heard something about C# exceptions having access to a stack trace, but why would that be beneficial and what would be a good way to demonstrate it in a short application?Or would it be better to just do a completely different feature? (My other two are Garbage Collecting and Array bounds checking). Possibly an example of everything in C# inheriting from object?I'm not 100% sure it has to be a difference from C++ either. Thanks for all your help so far!;Quote:Or would it be better to just do a completely different feature? (My other two are Garbage Collecting and Array bounds checking). Possibly an example of everything in C# inheriting from object?It is quite hard to justify any of those three is a really a good feature.   ;Quote:So going off this, would it be better to maybe use non-standardized libraries?I am not sure what you are asking here.Quote:I heard something about C# exceptions having access to a stack trace, but why would that be beneficial and what would be a good way to demonstrate it in a short application?Sounds like it is useful for debugging, but I wouldn't see this as a deal breaker if a language didn't support it.Quote:Or would it be better to just do a completely different feature? (My other two are Garbage Collecting and Array bounds checking). Possibly an example of everything in C# inheriting from object?Are you trying to show feature of C# that are superior to other languages? Or just to demonstrate any differences?While I haven't actually used C#, here are some things I think are interesting about what I've seen/read about the language.Delegates sound pretty great. Garbage collection is handy, along with "using" statements it sounds like it makes error handling not the awful experience it is in Java. Properties sounds interesting, but I don't have an opinion as to whether they are good. They are certainly better than Java's tendency to use set/get pairs, at least at the syntactic level. But I would worry about whether it makes programmers think in terms of get/set, rather than real objects with real actions. I've heard that C#'s generics are far better than Java's, which are (at least in the latest version of Java) purely syntactic sugar. I like the 'var' keyword, combined with the benefits of static typing. LINQ looks pretty fun.Also, the standardised bindings between all .Net languages and libraries (assemblies?) sounds fantastic too. Portability would be an issue for me however.Everything inheriting from some arbitrary base class is something I can live with, but its hardly a feature. More of a crutch. You can write C++ in the same manner if you wanted. I would prefer powerful generic programming features. Array bounds checking is pretty standard for any modern language, pretty much. C++ can even take advantage of this, usually by using drop in replacements for native arrays and with bounds checking only enabled in Debug mode.C++'s alternative to garbage collection, RAII, is usually preferable in my mind. While it has issues, it treats all external resources equally, which is a nice feature.   ;  Well the problem I'm having is I don't want my applications to just be kind of syntax differences. It's hard to find major differences between Java and C# and C++ and C# because they all have a bunch of very similar features.I am mentioning MSIL and the .net framework in the presentation, but I'm not doing it as an application.Just out of curiosity, why do u find delegates so appealing? Those would probably be a good thing to use though.   