Rename fatalError()

The main idea is to move away from the error concept altogether for the main “crashing” function.

It is only harmful when it becomes the default fixit instead of force unwrap or if it overloaded to provide default reasons as I linked in the proposal above.

It actually does not matter to me what end up spelling it, as long as it doesn’t contain the word error in the name. I’d be in favor of die but I also like panic.

Since when is a depreciation a breaking chance? If somebody chooses to turn “warnings as errors”, well, that’s an opt in conscious decision by the company or individual. At some point we should be given the option to turn off certain warnings in swift like clang or dotnet offers.

Perhaps it is inevitable that fatalError could not be sunset; should that stop us from providing a better name in a new function?

1 Like

die would be a good name, and definitely has brevity on its side. Something with failure to match assertionFailure and preconditionFailure might work as well.

2 Likes

How about generalFailure or unexpectedFailure?

1 Like

we could convine this idea and @DevAndArtist
into something like:

runtimeFailure()

I don’t think anybody would think that the actual runtime failed. Most people refer to crashing as runtime failures.

2 Likes

trap()

2 Likes

The suggestions in this thread seem to want to rename fatalError rather than redesign it. I'd like to point out links that look at fatal outcomes through redesign:

I think fatalError is a term of art, although I agree die is to the point.

I'm a little bit concerned about die(...) -> Never, because it reads really strange to me.

1 Like

Perl is immortal

6 Likes

It reads pretty well, in my opinion! "Die returns never": when you die, you never return.

3 Likes

Well I get that if you turn the words around then it makes sense, but ask less experienced developers or non-natives. It's almost like never dies which is definitely not what we want, but I guess this would apply to any function name in that particular case.

Personally I'm not a fan of die as a term of art but would rather prefer something like trap or terminate.

+1 for getting rid of the confusing Error suffix.

Also, if we're revisiting fatalError, perhaps we should look at other functions in the "die" family too. Lots of people I've seen struggle to remember the difference between preconditionFailure, assertionFailure and fatalError, advanced users and beginners alike.

I’d prefer to leave well enough alone. The names are meaningful, well-understood, and in common usage already. There is no problem that needs to be addressed here.

8 Likes

fatalError isn't marked throws and the "fatal" portion of the name makes it pretty clear that this is an unrecoverable error. I think we should leave well enough alone.

9 Likes

I dislike the idea of this pitch. I feel like adding a new top level function that is identical to the current fatalError() be it die(), trap(), or terminate() doesn't add any value or clarity.

While I can understand the dislike of Error being part of the name, it is very clear from the name that fatalError() is going to die, since it is fatal. Error being part of the name makes it clear that it is to be used when something has gone wrong.

Also, I would argue that try!, fatalError(), and forced unwrapping nil, etc. are unhandled and unhandleable exceptions.

I do not agree with die() or terminate() for the simple reason that was discussed about the possibility of adding a fatalError handler - e.g. for server-side applications where the process could perform additional diagnostics and/or re-launch the process. For such case, I believe that the fatalError is both well-descriptive and what it actually does - it states that the process ran into a fatal error. Which is more precise than die(), terminate(), fatal() (fatal what?), etc.

2 Likes

I considered editing my post to clarify that I don't really care to change the name of fatalError. I was simply struck by the thought that, if we are going to change the name, trap would mean that method did what it said on the tin.

2 Likes

I always thought to trap meant to switch to a debugger or some other monitoring tool, but not explicitly terminate the program, so using it to replace fatalError() doesn't seem a good alternative to me. It also sounds more like an implementation detail than what the user actually wants to happen.

I quite like die() as it's very brief and clear and is obviously separate from other ...Error() cases that might have handlers in the future.

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:

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

3 Likes

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.

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.

1 Like