Jump to content
  • Advertisement
Sign in to follow this  
beebs1

Error Handling in C++ Libraries

This topic is 3626 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hiya, I've noticed that a lot of C++ game libraries/middleware (such as DirectX, OpenGL, Havok, PhysX and FMOD) don't use exceptions, but use return codes instead. I was just interested in why this is? Is it that they are just slow to adopt exceptions, or maybe there's a more technical reason? Thanks very much for any explanations [smile]

Share this post


Link to post
Share on other sites
Advertisement
A good reason is that they often aren't C++ libraries, for the sake of interoperability. Both DirectX and OpenGL are written in C, for example.

Share this post


Link to post
Share on other sites
Interesting, thank you. I guess that's the reason why DirectX interfaces are in fact... structs.

But what about the rest? CryEngine and CryEngine 2 are both written in C++, but don't use exceptions - as far as I can see.

Thanks again.

Share this post


Link to post
Share on other sites
I always got the impression that throwing exceptions between libraries would be a bad idea. I don't know how it works specifically, but I wouldn't be surprised if there were a lot of gotchas involved in throwing exceptions between DLL's, for example.

I guess another reason is that it's safer to use a C-style interface. If the middleware provided some sort of custom exception class (which is very common, and expected when using exceptions), there's a lot of potential for stuff to go wrong. Differing compiler settings between your program and the middleware's library can cause different layouts of classes and structs for example, leading to bad things. This is also the reason why none of these middleware libraries would pass around C++ objects between your program and the library - it's always done through interfaces, handles, pointers, etc.

Share this post


Link to post
Share on other sites
I personally hate exceptions except maybe for really fatal stuff.

We had to use OGRE and some other libraries at uni and the use of exceptions severely hindered ease of coding. Personally, if (result == BAD) { } else { } is much more coder friendly.

The whole try catch thing just bloats code and makes it more difficult to do simple conditions to handle working function calls and non-working function calls.

Share this post


Link to post
Share on other sites
It is also probably in part because code that uses exceptions has historically been slower than code without it. The word is that compilers generate code now that has no overhead for try blocks (though I can't speak about whether the code size grows), but many engines are based on legacy code that was written when that wouldn't have been the case. It also means that game developers are less accustomed to using exceptions than perhaps other C++ developers have been.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
The word is that compilers generate code now that has no overhead for try blocks (though I can't speak about whether the code size grows), but many engines are based on legacy code that was written when that wouldn't have been the case.
Virtually every platform except IA32 uses table based exception handling these days, including AMD64. And VM languages like C# and Java uses them even on x86. If you're lucky the compiler/linker is even smart enough to split off exception handling code and tables into separate segments which can be paged in on demand, making the size overhead negligible (unless you're actually optimizing for disk space rather than improved cache use).

Of course even if the tables and handling code are placed far away the performance overhead is still not zero as proper cleanup inhibits many other optimizations and transformations. The real question is whether the final performance is comparable to manual error handling or not, clearly a question without an obvious answer.

Another reason that exceptions are commonly perceived to be slow is that many projects seem to use them exclusively to deal with every possible error rather then allowing any fatal conditions, which is fine if the application needs to be robust enough to deal with it and there are code paths somewhere to actually resolve the problem, but if it's merely propagated to the top of the call stack and used to display an error message then you're just wasting cycles.

However I suspect the main reason that exceptions are avoided in games is that early console tool chains tend to have all kind of issues with them, ranging from performance problems to outright bugs. That is if you want to be ready to support a "next-gen" console then exceptions are a big risk.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!