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: 
1) Throwing exceptions is an expensive operation. The C++ philosophy is not to pay for what you don't use. If you want exceptions, you throw them yourself (or use libraries that do).

2) Never accept the divide by zero error. It depends on the situation, if you know the input will never be a 0 never check for it. If you are unsure, always check for it. Then either throw an exception, or swallow the error quietly. It is up to you.

3) Exception throwing, especially combined with RAII can make for truely elegant and beautiful code. This may not be acceptable in all situations. You may have 100% confidence in your inputs and wish for raw performance. If you are creating a DLL you do not really want to be throwing exceptions out of your api, but for a critically consistant statically linked library you would be advised to.
1. Because C++ is intended to be "close to the metal" and mostly tries to pass simple operations like division through to the hardware relatively directly (so if you can't depend on hardware to enforce a constraint, C++ probably won't by default either).
2. I don't think there's a universal answer to that. Some C++ programmers write almost C-like code that almost never uses exception handling. Others use exception handling quite rigorously (and most are somewhere in between).
3. While there's almost certainly a correlation between OO and exception handing, I don't think it's really cause and effect. The factors that seem likely to me are:
	1. OOP and exception handling tend to be most useful in similar (e.g., large) projects.
	2. OOP and exception handling have both become more common over time. Older OO languages often lack exception handling. Newer languages often have exception handling, even if they're not OO at all.