Divide by 0 causes most CPUs to follow some kind of escalation procedure which may be called an exception, signal, interrupt, trap or whatever in that CPU manufacturer's jargon. None of these - even if the term "exception" is also used - have any direct relationship to C++ language exceptions.
In C++, because it's generally expensive in CPU cycles and object code size to test repeatedly for divide by zero, compiler generated code for the inbuilt types is not required to do any such checking. In practice, it's usually sufficient to trust that the programmer will code to avoid a divide by zero, inserting explicit checks in the subset of divisions where they're useful; factoring such checks to avoid redundancy.
If the programmer wants a consistent guaranteed check, they can create a User Defined Type (a class with custom overloaded operators) that can be used in place of an inbuilt numeric type, but takes the time to check for division by zero (or underflow, overflow or whatever other concerns the developer has) and reacts however the programmer likes. I gather that languages like JAVA and C# lack operator overloading, which I'd imagine means they can't painlessly replace an inbuilt type in this way, needing invasive code changes to explicitly call functions instead of using the intuitive mathematical operators.
Anyway, as the C++ Standard itself doesn't specify some behaviour for divide-by-zero situations, the implementation's free to provide some potentially useful behaviour if it chooses. That could imaginably include somehow generating an actual C++ language exception, but in practice it's likely to be too expensive in CPU cycles and code size to justify. Perhaps JAVA is so slow and bloated anyway that a little extra checking like this is neither here nor there...? ;-)
Say you're on a x86-family CPU, the term for a divide by 0 notification is "interrupt". But, if that machine's running say UNIX or Linux, the division results in a "signal" at the Operating System level, and you can set a signal handler to get notification of the problem.