Type Safely

Share this post
Using The Never Type To Deal With Fatal Errors
typesafely.substack.com

Using The Never Type To Deal With Fatal Errors

Daily Coding Tip 117

Rob Sturgeon
Jun 27
Share this post
Using The Never Type To Deal With Fatal Errors
typesafely.substack.com
Image by Markus Kammermann from Pixabay

If you’ve used fatalError in Swift, you may have noticed that it is a function with a return type of Never.

This type name may seem confusing, but it is actually somewhat similar to returning nil. Optionals in Swift are actually a generic type, where let myString: String? = nil is equivalent to let myString = Optional<String>.none.

The Optional enum also has a .some("My string") case, which is what exists when an optional value is not equal to nil.

If you assign a fatal error to a constant, for instance let error = fatalError("error"), Xcode will give a warning that explains a lot:

Constant 'error' inferred to have type 'Never', which is an enum with no cases. Add an explicit type annotation to silence this warning.

So instead of being an enum with a .none case, like the generic Optional enum, the lack of cases is enough for us to confirm that nothing exists here.

The interesting thing about returning a type of Never is… you never will.

In a function returning a known type, it is possible to call fatalError instead of returning anything.

Whenever a Never type is created, execution of the code is immediately and unconditionally halted. In other words, the app will crash.

This makes it impossible to store a Never object, as its very creation will crash the app.

Here’s an example of how to use computed properties to return a Never object, because that’s the closest you can come to storing them as a variable.

MyErrors.swift

Because I have explicitly stated the type Never, Xcode will not give me a warning about the type being an enum with no cases. I’ve also added a function that creates a custom error with whatever text I want to be displayed.

Whenever these properties and functions are called, code execution will immediately stop and highlight one of these lines.

The error will not highlight the place where they were called, even if I was assigning one of these to a variable elsewhere.

Now let’s write some SwiftUI!

FatalErrorNeverContentView.swift

This simple Form allows for the creation of the errors.

The action for a Button requires a closure that returns Void, so we can’t return Never directly. However it is possible to simply call the computed values without assigning them, as was the case with MyErrors.wrongError. The other two known errors provide different ways that you can try to use the Never type, but this code will never be executed and the fatal error will still be thrown from within MyErrors.

Finally we have a custom error section with a TextField for writing a message at runtime.

Despite the fact that the created error is assigned to a local constant within the button’s action closure, the fatal error will once again be thrown from within MyErrors.

Last Week’s Daily Coding Tips

  1. Use a Custom Type To Populate The New Grid Layout With Data

  2. Snap a Sheet To Multiple Heights Like In Apple Maps With Presentation Detents

  3. Use AnyLayout To Choose a Layout at Runtime

  4. Use a Custom Type To Populate The New Grid Layout With Data

Share this post
Using The Never Type To Deal With Fatal Errors
typesafely.substack.com
Comments

Create your profile

0 subscriptions will be displayed on your profile (edit)

Skip for now

Only paid subscribers can comment on this post

Already a paid subscriber? Sign in

Check your email

For your security, we need to re-authenticate you.

Click the link we sent to , or click here to sign in.

TopNewCommunity

No posts

Ready for more?

© 2022 Type Safely
Privacy ∙ Terms ∙ Collection notice
Publish on Substack Get the app
Substack is the home for great writing