Question: In the course of asking about catching 'divide by 0' exception, I found that with C++, we can't do that. I mean, divide by 0 doesn't throw an std::exception. 

Some of the hints that I found were I have to check the value, and throw the exception by self.

I say it's confusing, as I've thought that C++ adopted the exception idea in order to replace the 'good old C/UNIX report error by returning value method'.

Here are my questions

* Q1 : Why C++ doesn't throw std::exception error for divide by 0? Is there any reason behind that?
* Q2 : Normally, what error processing scheme the C++ users use? Always throw an error, and the exception is the divide by 0 error?
* Q3 : In general, OOP languages prefer (or even enforce) using exception. Is this correct?

Answer: 
C++ is implemented on many different platforms and is designed to support high-performance applications. Allowing undefined behaviour means than not all uses of division need to be burdened by extra checking and a possible exception throw by the compiler. The compiler is allowed to implement the fastest translation of divide in machine code regardless of its behaviour on divide by zero.

As with performing any operation, it is the programmers responsibility to ensure that any pre-conditions are met. In the case of division, a programmer may *know* that the divisor cannot be zero (or very small) and may just use an assert; in other cases he might need to validate the input and throw an application specific exception if the conditions aren't met.

C++ isn't (just) an OO language and doesn't (in most cases) enforce the use of exceptions. It provides them as a tool for use where appropriate. There are other languages which force the use of exceptions to a much greater degree.
About Q3 - exceptions are something which should occure exceptional :)
So to avoid (which is possible with div0) is always better.
Additionally to Emyr (who is right about "avoid wasted cycles for calculation") you should consider that throwing an exception means a lot of "internal work" since the context changes (you may leave loop, functions, instance methods....) and your "excpetion stack" has to be prepared.

So in general exception handling is "the common method" to handle exceptions. But it should not be a pattern to avoid "value checking".

if(!string.IsNullOrEmpty(....) ...
is much better than
try{
xx=MyMabeNullString.Length...
}
catch{
//errmess - I could have checked it before :)
}