It's not even that, this can be (and probably is) implemented with dynamic variables (or some similar mechanism). You can also implement exceptions with setjmp and longjmp in C.
I feel the most important thing is conventions, and having a weaker model of exceptions as a convention, affects all/most code in the platform. In Java most libraries throw exceptions and so you will probably use exceptions. In C most libraries return an int return value for error/success and you'll probably use that. In Common Lisp, people use conditions.
So, what I'm trying to say, is that when considering this kind of design decisions in a language, we have to take into account how it affects the whole platform (and not just see if it is possible to implement it any other way in our particular language of choice). The same reasoning should be applied for object orientated features, scoping rules, calling conventions, multiple-value returns, lazy evaluation, macros, continuations, modules, type systems, naming conventions, etc.
I feel the most important thing is conventions, and having a weaker model of exceptions as a convention, affects all/most code in the platform. In Java most libraries throw exceptions and so you will probably use exceptions. In C most libraries return an int return value for error/success and you'll probably use that. In Common Lisp, people use conditions.
So, what I'm trying to say, is that when considering this kind of design decisions in a language, we have to take into account how it affects the whole platform (and not just see if it is possible to implement it any other way in our particular language of choice). The same reasoning should be applied for object orientated features, scoping rules, calling conventions, multiple-value returns, lazy evaluation, macros, continuations, modules, type systems, naming conventions, etc.