The statement "at the native level at runtime of any language," is an oxymoron. All native parts of exception handling are platform, not language, dependent. Some parts of exception handling are even hardware dependent (Divide by zero is always a hardware exception, for instance.)
In the specific case of divide by zero on .NET, on Windows, on x86, it goes something like this:
- Your application tries to divide by zero.
- The CPU saves some application state and executes code located the "Divide Error" address in the trap table (which so happens to be the zeroth element of the trap table.)
- The trap handler code (which is part of the Windows Kernel) triggers mechanisms to eventually (in the executive) raise an SEH exception for divide by zero which will be propagated into the Object Manager, then into the .NET runtime.
- The .NET runtime code in mscoree.dll gets the divide by zero as an HRESULT COR_E_DIVIDEBYZERO from a COM object.
- .NET converts the HRESULT into a System.DivideByZeroException.
- Your code sees the exception as a glorified long jump to the "closest" enclosing catch block, or finally block.
- You either handle the exception, or it gets propagated out of your code and then your application crashes.
In general, you can think of exceptions as long jumps that carry a pointer to some Thread-local state information (the exception). The target of the long jump is usually known at compile time.
Not every language has exception handling built in, either. C, for instance, does not have structured exception handling.