Why no exceptions?

[dneise]

I wonder, why so often return values are used to check if a method works in Mars.
Why are exceptions used so rarely? I checked it ... they work, also on the ROOT interpreter, so this time it's not ROOTs fault ;-)

I propose to make more use of exceptions and put missing exceptions in asap.

[tbretz]

This is mainly historical because at a time root was not supporting exceptions, Mars was compiled without exception support to speed up things. Nowadays this is not a stong argument anymore that's why for example FACT++ is using exceptions. However, exceptions have a couple of drawbacks and they are not the default method of choice. As long as there is no reason not to use a return code... use a return code.

Apart from the fact that they still can slow down code excution significantly, they also break a clear program flow and make a single line function call a monster. Mars is constructed such that it doesn't need exceptions at all (and they would help at all because they would just break the structure), but there are certainly single use cases (mostly very basic functions) where they make sense. As an example you can think of a numerical calculation which return a value or fails (e.g. devision by zero). In such a case you need to ensure that whenever the function is called you catch the exceptions... otherwise you render them useless and just add more 'Mars is broken... it crashed." cases.

[dneise]

Replying to tbretz:

[...] exceptions have a couple of drawbacks and they are not the default method of choice.
As long as there is no reason not to use a return code... use a return code.

You make this sound like a fact and while it is certainly your honest opinion, others might think different.

I think, a lot of authors have elaborated on this matter extensively, but a nice write-up is certainly to be found here:
​http://www.codeproject.com/Articles/38449/C-Exceptions-Pros-and-Cons

Other interesting remarks, but certainly less balanced can be found in Robert C. Martins "Clean Code" [2008, chapter 3, p.46].

Also Sutter and Alexandrescu provide some insights in their classical "C++ Coding Conventions" [2005, chap. 72, p.140]

[kbruegge]

Hi

While the Checked vs Unchecked exceptions discussion is certainly a hotly debated topic in todays software development, the case for using exceptions in general surely isn’t.

All exceptions in C++ are unchecked exceptions, which is exactly what we want since the public interfaces of your objects and methods do not change. And the caller isn’t forced to handle the error immediately. Readability is certainly better when using exceptions.

While the former should be reason enough to use exceptions for error handling there is also no performance loss whatsoever. The opposite might even be the case because the program has less possible execution paths for the compiler to handle.

[tbretz]

Replying to kbruegge:

All exceptions in C++ are unchecked exceptions, which is exactly what we want since the public interfaces of your objects and methods do not change. And the caller isn’t forced to handle the error immediately. Readability is certainly better when using exceptions.

That is not true... unchecked exceptions (be it C++ exception or unhandled error cases) are exactly the reason why most data acquisition systems or other systems are not stable.

Your statement is true if you have a very well designed system of exceptions in which it is clearly defined when which functions throws which exceptions and more improtant the corresponding action is well defined. This does not work AT ALL in the way physicists write software. The result will be unhandled crashes because the first person who coded the exception didn't handle it because he thought it will never happen anyway, the one who wrote the next layer didn't know about it and the maintainer of the package has lost track of the origin and can do nothing than stop the program.

For most students exceptions are still hidden magic and are recognized as "my program crashed". It is obvious that a function returning an error code might need handling of that code. It is not at all obvious whether a function throws exceptions (and it can be hidden very deep in the code).

While the former should be reason enough to use exceptions for error handling there is also no performance loss whatsoever. The opposite might even be the case because the program has less possible execution paths for the compiler to handle.

This is not true either. Every exception needs a second return value on the stack. Now modern CPUs have special instructions to handle those exception cases. The trick usually is that they predict the most probably case, namely that an exception will not occur (jump prediction). As long as exceptions stay exceptional, this works well and slow down the program in the exception case (which shouldn't matter). But once you introduce exceptions for all and everything, somebody will have the clever idea to use them instead of a return statement.

Exceptions are a nice tool. And there are good reasons to have them and use them. But they need a very good design to give an improvement. Just using exceptions doesn't give any improvement. Just the opposite is the case. This is by the way true for most C++ features.

As long as exceptions are not needed, you only gain complexity. As soon as exceptions significantly reduce complexity they are a tool worth to consider. In any case if they are used generally, a well designed exception-system is mandatory -- and exactly 'well designed' is what most projects fail. So keeping things simple (not necessarily the framework, because you debug that only once, but the actual processing code) is usually the key to avoid problems.