1. exceptions have that name because are intended to handle event out of normal , error and not to returns value or information to the caller. No skilled C++ developer will write functions like those, never !
2. In that kind of function exception are useless, in fact that should be write like this, with exception disabled:
int calc(int a, int b) noexcept {
if(... omissis ...) return 1; return 0;
}
3. In case the function had some more complex errors, the correct form for the use of exceptions should be:
int calc(int a, int b) {
try{
// More complex logic here
if(... omissis ...) return 1; return 0;
} catch(myexcept& ex){ // do something // possibly other catch for different except here } catch(...){ // do something }
}
So, not to return information but for error handling.
3. From a skilled developer , from a financial company, I expected a real life example , with correct exception use and a real case in which their presence can slow down a critical section of a program. That could be an interesting lesson;
4. Moreover, the examples are particularly bad because could induce people to think that in other contexts, where performance are not so important, the use of the exceptions in that way is justifiable ! I guess that could be a reason the article was downvoted.
5. I hate "dogma driven programming", IMHO to demonise whole class of features of a language without critical sense is wrong: yes most application has critical sections that are performance sensitive but, also frequently, large portions of them are not. So why make programmer's life miserable banning without think features like exceptions or polymorphism "because is written"? Moreover, if some little parts is justified that are written even in Assembly, maybe large chunks could be written in Go or Python without influence on the general performance of the system.
Until it finds its way into mainstream, I prefer the C/Golang approach.
