Errors are things that can fail after the program is written (hard drive crash, network failure, etc.).
Exceptions are things that were already broken when you wrote the code (null pointer access, index out of bounds, etc.)
To put it another way, exceptions are failures that a sufficiently smart compiler would have been able to catch at compile time. Of course, creating a compiler that smart is a monumental task, so we accept catching some programmer mistakes at runtime as a reasonable tradeoff.
If you are trying to suggest that the stack is runtime unpredictable like a hard drive, overflowing it would be an error, not an exception.
Therefore, a sufficiently smart compiler just needs to ensure that you have done the proper accounting of stack use and handle the error condition if you are approaching an overflow state. With that, you can prevent it becoming an exception.
If you encounter a stack overflow exception, it is because you didn't do your due diligence. Technically your program is flawed. Granted, the pragmatic engineer probably doesn't care about correctness in that area. It turns out not all programs have to be perfect to be useful.
No fame for me, I'm afraid. There is nothing here out of the ordinary.
Exceptions are things that were already broken when you wrote the code (null pointer access, index out of bounds, etc.)
To put it another way, exceptions are failures that a sufficiently smart compiler would have been able to catch at compile time. Of course, creating a compiler that smart is a monumental task, so we accept catching some programmer mistakes at runtime as a reasonable tradeoff.