It is a design choice to make range checks a fatal error rather than a catchable exception. Those are meant for handling expected runtime failure conditions, not something that is quite clearly a programmer error.
It is not a choice everyone will agree with. I am not sure I agree with it. But it is by design, not an oversight. Making something a catchable exception will affect the function signature (add “raises”) and any code that uses it.
I understand the spirit. So if you have an application that manipulates your data, and it gets into a state that was not expected, what do you do?
There is a wrong answer. In C and C++, you just do random shit. The program you are running could start deleting all your files. Who knows? I don’t think we want this anymore.
Swift seems to be going with… let us crash hard.
Is that good?
Oren Tiroshsays:
Another way of saying the same thing is to note that Swift automatically puts ASSERT() on all array indexing operations.
Now the arguments around assert, what is or isn’t worth asserting, assertions on debug vs release builds etc are all old and well-hashed. And definitely not settled conclusively one way or the other.
Perhaps the most controversial thing Swift has done here is calling it a “crash” rather than “assertion failed – range check error”.
It is a design choice to make range checks a fatal error rather than a catchable exception. Those are meant for handling expected runtime failure conditions, not something that is quite clearly a programmer error.
It is not a choice everyone will agree with. I am not sure I agree with it. But it is by design, not an oversight. Making something a catchable exception will affect the function signature (add “raises”) and any code that uses it.
I understand the spirit. So if you have an application that manipulates your data, and it gets into a state that was not expected, what do you do?
There is a wrong answer. In C and C++, you just do random shit. The program you are running could start deleting all your files. Who knows? I don’t think we want this anymore.
Swift seems to be going with… let us crash hard.
Is that good?
Another way of saying the same thing is to note that Swift automatically puts ASSERT() on all array indexing operations.
Now the arguments around assert, what is or isn’t worth asserting, assertions on debug vs release builds etc are all old and well-hashed. And definitely not settled conclusively one way or the other.
Perhaps the most controversial thing Swift has done here is calling it a “crash” rather than “assertion failed – range check error”.
I called it a crash because in release mode, you get no message, just a program termination.