Add a proper exception system to TSC

[Quintus]

Currently, SMC has no concept of exception handling. It prints wealths of warnings, whose conditions may even crash the game later on and which make debugging unneccessarily hard because you have to manually determine where the warning came from rather than just having GDB figure out where an exception popped up from. A proper exception system should use proper exception classes which useful error messages and a good exception hierarchy.

[datahead8888]

This sounds good, but I had one question.

I've heard people say that there's an unacceptable cost if you add exception handling to C++ programs. I've thus wound up avoiding it and returning true or false from functions to indicate success or failure. Do you have any sources on the performance implications of adding exception handling in C++? It may also be relative to the compiler used for these sources.

Secret Maryo Chronicles is probably not as performance intensive as something such as Doom, but it's worth discussing for the sake of understanding.

[Quintus]

I've heard people say that there's an unacceptable cost if you add exception handling to C++ programs. I've thus wound up avoiding it and returning true or false from functions to indicate success or failure.

The people saying this miss the point of exceptions. When an exception needs to be thrown, you have encountered a situation where normal gameplay is impossible. That is, the exception’s whole purpose is to disrupt gameplay. If you can’t continue normal gameplay anyway, you are in a situation where performance does not matter anymore. What now matters is to convey as much information as possible (by crashing the game with an informative message), so the developers can easily and immediately see where the exception popped up from by running the game in GDB and unwinding the stack.

During normal gameplay exceptions should not be thrown. But if you fail to load a level file you reach a point where you don’t care about performance. Instead, you want as much information about the failed loading as possible.

've thus wound up avoiding it and returning true or false from functions to indicate success or failure.

This is C-style code, and makes it very hard to find the cause of a later crash because you just can’t find out what exactly went wrong, where a function returned false where it shouldn’t had. Throw an exception instead of return false, and you directly arrive at the place of the problem, including call path.

Vale,
Quintus

[datahead8888]

Actually the line that people quote is that you will have something like a 20% reduction in performance in code ALL of the time if you use exceptions at all, not just a penalty when exceptions are thrown. I'm not saying it's correct, but there apparently have been people saying this.

I'd be interested in being involved in this task (to get a better feel of the C++ way of doing exceptions). I've worked with the Java and (to some extent) C# models, but I haven't done that much with it in C++.

I'd rather not directly be assigned to it but maybe can contribute some code snippets or help figure out some concepts. It's probably more important I be assigned to the GLSL task if I work a task (and the quicksand task would go with it). We could take turns being assignees, too - whatever works.

[Quintus]

We have exceptions anyway, because CEGUI and libxml++ use them. So deciding whether to use them or not is not entirely our own decision. And given they are in anyway, adding our own exceptions will possible not fulfill

20% reduction in performance in code ALL of the time if you use exceptions at all

as this exists anyway.

Vale,
Quintus