Rename fatalError()

[yxckjhasdkjh]

Reading this thread, and also the other one about "unwrap or die", it seems that there is a fundamental philosophical divide between people who think that fatal errors are good and should be encouraged and those who think that they are bad.

While I can understand the side of the people who say "never crash your app", after reading (or rather skimming) this reliability proposal it seems to me that that philosophy is not in agreement with the Swift philosophy - please correct me if I'm wrong. It says there:

Swift handles these with a fail fast philosophy: it is preferable to detect and report a programmer error as quickly as possible, rather than "blunder on" with the hope that the error won't matter.

Personally, I agree with this, whereas I disagree with the OP's assessment that

My major objection to the current name is that it contains the word "Error". I believe this is leading people to treat it as a way to throw unhanded exceptions 13 (which swift does not have). I do not think this is a good path for swift. If we were to introduce an extensible way to fatalError() then at some point people are going to ask for swift to be able to handle those fatal errors and at this point we are back to just having plain Java like Exceptions.

[masters3d (Chéyo Jiménez)]

@yxckjhasdkjh

it seems to me that that philosophy is not in agreement with the Swift philosophy

I read that too an come away with a completely different understanding.

1. Failures are very close to what cocoa calls exceptions
2. Failures are good in some case and not good in others.
3. We should do something about fault tolerance.

A proposal by a core team member does not make it a swift philosophy. Moreover, proposing to rename fatalError on the grounds that error is a bad name for an exception like “construct” has nothing to do with what people think of runtime failure.

Do we really want to call runtime failures, errors? That’s the premise of this proposal.

If fault tolerance means that we are introducing exceptions, well then, I would still argue that fatalError should be renamed. Perhaps then a better name would be fatalException.

[yxckjhasdkjh]

@masters3d

Do we really want to call runtime failures, errors? That’s the premise of this proposal.

Do you really think there is a principled difference between "errors" and "exceptions"? I mean, sure, I could argue that there is a semantic difference, but in my experience with several programming languages, I rather feel like such a distinction would be totally arbitrary.

[calebkleveter]

I think crash() is a pretty self-explanatory name. kill() might also work if you are go down the Unix nameinf route.

[masters3d (Chéyo Jiménez)]

Within the current Swift context, Error is divorced from the common connotation of exception error which force a crash. In a purely language aspect of the word they are synonymous.

#error does pose an issue. A compile time error and “user error” are errors but not related to Swift’s Error type.

Perhaps Error should’ve not been taken after NSError.

Do you know of any other languages that use the name error in the main crashing function?

[yxckjhasdkjh]

@masters3d

Do you know of any other languages that use the name error in the main crashing function?

I guess almost all other languages I know (except maybe C) of don't generally have completely unrecoverable crashes.

Haskell for example has "error"; which is probably the most like Swift's fatalError, but even that can be caught in the IO monad, afaik. In interpreted languages (that I know, including Java), usually everything is recoverable, since the runtime can just deal with it. Ruby has RuntimeError which is mostly what you use for a programming error. Java is weird in that it has checked and unchecked exceptions (the former of which have to be declared in every function), but "Error" is unchecked, while everything that inherits from "Exception" is checked, unless it inherits from "RuntimeException", then it's also unchecked... go figure.