5 ms·

A tad off topic but worth pointing out nevertheless: In C++ "exceptions should be exceptional", you don't need to fill you program with try/catch blocks and sh

A tad off topic but worth pointing out nevertheless: In C++ "exceptions should be exceptional", you don't need to fill you program with try/catch blocks and shouldn't. Use return values instead (better performance, flow less bug prone). Never forget that an exception is essentially a goto statement. In other words, you need rarely more than one try/catch block per thread.

PaulHoule 15y ago
Using return values to pass back error codes is a disaster waiting to happen that can triple your line count.
- shin_lao 15y ago
  Please explain.
grogs 15y ago
Goto statements are not as horrific as comp sci 101 lectures suggest. This is especially true when compilers do it, pretty sure JMP statements are used for function calls.
- Ralith 15y ago
  > This is especially true when compilers do it, pretty sure JMP statements are used for function calls. That's a bit silly. It's like saying that writing raw opcodes is okay because the assembler does it.
- zedadex 15y ago
  No. http://en.wikipedia.org/wiki/Jump_to_subroutine#Jump_to_subroutine http://en.wikipedia.org/wiki/Jump_to_subroutine#Jump_to_subr...
Silhouette 15y ago
By my count, you have made five substantially different claims there: in C++, exceptions should be exceptional; you rarely need more than one try/catch per thread; return values give better performance; return values make the flow less bug prone; and an exception is essentially a goto statement. I challenge every one of those five claims. Can you provide a reasoned argument and/or empirical data to support them?
- shin_lao 15y ago
  Exception performance is pretty obvious: you need to unwind the stack everytime you catch an exception whereas checking an error return value is one instruction long. If you try to catch your exception at every statement, you're not using RAII correctly. Returns values are less bug prone because behaviour is obvious (boost::system::error_code is a good way to encapsulate information). Exception is a goto statement because basically you're breaking the flow and saying "go to catch in case of error". For all these reasons, exceptions should be exceptional. Use exceptions for abnormal behavior that you cannot properly handle in the program (out of memory, i/o error...).
  - Silhouette 15y ago
    Exception performance is pretty obvious: you need to unwind the stack everytime you catch an exception whereas checking an error return value is one instruction long. It's not obvious at all. You need to unwind the stack anyway. If you do so using some form of jump table when an exception is thrown, you only have a single step to deal with instead of a whole series of returns. Moreover, on the non-exceptional path, you no longer need check-and-branch logic after the return from every function that might fail. If you try to catch your exception at every statement, you're not using RAII correctly. Sure, but that doesn't imply your conclusion that usually you would only want one try/catch per thread. Why can't we catch an exception at whatever level of our code knows how to respond to that situation? Why would we assume that the only levels of logic in our code are low-level work that might throw and a top-level oversight loop? Returns values are less bug prone because behaviour is obvious (boost::system::error_code is a good way to encapsulate information). C++ does non-obvious things all the time, and that can be helpful because it removes unnecessary details so that we can concentrate on the logic that matters. Would you also argue that using RIAA is bad because if we explicitly released all our resources before every possible return from the function it would make the behaviour obvious? Exception is a goto statement because basically you're breaking the flow and saying "go to catch in case of error". Except that you're not just saying "goto catch", are you? Like return, continue and break statements, exceptions can only transfer control to another location in a structured way, in this case, the equivalent of returning early from the lower-level functions and going back up the call stack. You can't escape the structured programming roots of the code using an exception the way you can with goto, and the semantics of unwinding the stack when an exception is thrown are well defined and widely understood. For all these reasons, exceptions should be exceptional. Use exceptions for abnormal behavior that you cannot properly handle in the program (out of memory, i/o error...). Sure, that's one useful role for exceptions, but why should we limit our use of a tool based on what the tool happens to be called? I don't think they had modern C++ libraries and metaprogramming in mind when they added templates to the language.

PaulHoule 15y ago

Using return values to pass back error codes is a disaster waiting to happen that can triple your line count.

shin_lao 15y ago
Please explain.

grogs 15y ago

Goto statements are not as horrific as comp sci 101 lectures suggest. This is especially true when compilers do it, pretty sure JMP statements are used for function calls.

Ralith 15y ago
> This is especially true when compilers do it, pretty sure JMP statements are used for function calls. That's a bit silly. It's like saying that writing raw opcodes is okay because the assembler does it.
zedadex 15y ago
No. http://en.wikipedia.org/wiki/Jump_to_subroutine#Jump_to_subroutine http://en.wikipedia.org/wiki/Jump_to_subroutine#Jump_to_subr...

Silhouette 15y ago

By my count, you have made five substantially different claims there: in C++, exceptions should be exceptional; you rarely need more than one try/catch per thread; return values give better performance; return values make the flow less bug prone; and an exception is essentially a goto statement. I challenge every one of those five claims. Can you provide a reasoned argument and/or empirical data to support them?

shin_lao 15y ago
Exception performance is pretty obvious: you need to unwind the stack everytime you catch an exception whereas checking an error return value is one instruction long. If you try to catch your exception at every statement, you're not using RAII correctly. Returns values are less bug prone because behaviour is obvious (boost::system::error_code is a good way to encapsulate information). Exception is a goto statement because basically you're breaking the flow and saying "go to catch in case of error". For all these reasons, exceptions should be exceptional. Use exceptions for abnormal behavior that you cannot properly handle in the program (out of memory, i/o error...).
- Silhouette 15y ago
  Exception performance is pretty obvious: you need to unwind the stack everytime you catch an exception whereas checking an error return value is one instruction long. It's not obvious at all. You need to unwind the stack anyway. If you do so using some form of jump table when an exception is thrown, you only have a single step to deal with instead of a whole series of returns. Moreover, on the non-exceptional path, you no longer need check-and-branch logic after the return from every function that might fail. If you try to catch your exception at every statement, you're not using RAII correctly. Sure, but that doesn't imply your conclusion that usually you would only want one try/catch per thread. Why can't we catch an exception at whatever level of our code knows how to respond to that situation? Why would we assume that the only levels of logic in our code are low-level work that might throw and a top-level oversight loop? Returns values are less bug prone because behaviour is obvious (boost::system::error_code is a good way to encapsulate information). C++ does non-obvious things all the time, and that can be helpful because it removes unnecessary details so that we can concentrate on the logic that matters. Would you also argue that using RIAA is bad because if we explicitly released all our resources before every possible return from the function it would make the behaviour obvious? Exception is a goto statement because basically you're breaking the flow and saying "go to catch in case of error". Except that you're not just saying "goto catch", are you? Like return, continue and break statements, exceptions can only transfer control to another location in a structured way, in this case, the equivalent of returning early from the lower-level functions and going back up the call stack. You can't escape the structured programming roots of the code using an exception the way you can with goto, and the semantics of unwinding the stack when an exception is thrown are well defined and widely understood. For all these reasons, exceptions should be exceptional. Use exceptions for abnormal behavior that you cannot properly handle in the program (out of memory, i/o error...). Sure, that's one useful role for exceptions, but why should we limit our use of a tool based on what the tool happens to be called? I don't think they had modern C++ libraries and metaprogramming in mind when they added templates to the language.