This article is an example of how we can do research into Swift Standard Library functions behavior building our knowledge not only on the Library documentation but also on its source code. All events which programmers call "errors" can be separated into two types. The events of the first type are processed in a regular control flow. For example, we react to network failure by showing a message to a user and setting an app to wait for network connection recovery. We try to find out and eliminate events of the second type as early as possible before the code goes to production. One of the approaches here is to run some runtime checks terminating program execution in a debuggable state and print a message with an indication of where in the code the error has happened. For example, a programmer may terminate execution if the required initializer was not provided but was called. That will be invariably noticed and fixed during the first test run. Another example is the switching between indices (let's assume that for some reason you can't use enumeration). Again, a programmer is going to cause crash during debugging here in order to inevitably notice a bug in indexing. There are five terminating functions from the Swift Standard Library (as for Swift 4.2). Which of the five terminating functions should we prefer? Let's look at the source code. We can see the following right away: Now let's look at documentation. We can see the following right away. We may conclude that the configuration evaluated in the four terminating functions is set by these build flags. Although configuration evaluation functions are designed for internal usage, some of them are public for testing purposes, and we may try them through CLI giving the following commands in Bash. These tests and source code inspection lead us to the following rough conclusions. There are three mutually exclusive configurations. NB: These conclusions are not the strict definition of when debug builds or release builds take place. It's a more complex issue. But these conclusions are correct for the context of terminating functions usage. Let's look not at what the -Ounchecked flag is for (it's irrelevant here) but at what its role is in the context of terminating functions usage. Speaking more directly, you must not allow reachability of the following four terminating functions with the -Ounchecked build flag set for your program. Use only fatalError(_:file:line) while applying -Ounchecked and at the same time allowing that the point of your program with fatalError(_:file:line) instruction may be reachable. Two of the terminating functions let us check for conditions. The source code inspection allow us to see that if condition is failed then function behavior is the same as the behavior of its respective cousin: That knowledge makes further analysis easier. Eventually, further documentation and source code inspection allows us to formulate the following table.  It is clear now that the most important choice for a programmer is what program behavior should be like in release if a runtime check reveals an error. The key takeaway here is that assert(_:_:file:line:) and assertionFailure(_:file:line:) make the impact of program failure less severe. For example, an iOS app may have corrupted UI (since some important runtime checks were failed) but it won't crash. But that scenario may not be the one you wanted. You have a choice. Never is used as a return type of function that unconditionally throws an error, traps, or otherwise do not terminate normally. Those kinds of functions do not actually return, they never return. Among the five terminating functions, only preconditionFailure(_:file:line) and fatalError(_:file:line) return Never because only these two functions unconditionally stop program executions and therefore never return. Here is a nice example of utilizing Never type in a command line app. (Although this example doesn’t use Swift Standard Library terminating functions but standard C exit() function instead). If printUsagePromptAndExit() returns Void instead of Never, you get a buildtime error with the message, "'guard' body must not fall through, consider using a 'return' or 'throw' to exit the scope". By using Never you are saying in advance that you never exit the scope and therefore compiler won't give you a buildtime error. Otherwise, you should add return at the end of the guard code block, which doesn't look nice.