I'm writing a program in Swift which has various functions which should always return values, but in some cases cannot, and so the program crashes and alerts the user of the error. To accomplish this, I am using implicitly unwrapped Optionals as return values for my functions, so that error cases can just return nil (even though that code will never be reached). It looks something like this:
func giveMeAThing() -> Thing! {
if !possibleErrorCase() {
var thing = createAThingForSure()
return thing
}
else {
crashAndBurn()
return nil
}
}
Writing this, it feels a bit hacky, so my question is whether or not this is a good use of implicitly unwrapped Optionals in Swift. Is there a better way to structure my code that will avoid this?
It may be that the piece of the puzzle you are missing is @noreturn. If you declare a function as @noreturn, the compiler abandons any complaints if you don't fulfill the surrounding contract. Thus you can call such a method and not return any value, and the compiler will not complain because it knows we are going to die anyway. For example, fatalError and abort are declared this way.
Thus, the following is legal:
func f() -> String {
fatalError("oooooops")
}
That compiles even though we fail to fulfill the contract of returning a value, because @noreturn (in the declaration of fatalError) tears up the contract and flushes the pieces down the toilet.
Another possible way of approaching the same issue is to use assert. This crashes and burns for you if a condition is not met. So, in your example:
func giveMeAThing() -> Thing {
assert(!possibleErrorCase(), "gaaaaah!") // crash and burn if error case
return createAThingForSure()
}
The downside is that by default all asserts succeed in a shipping app. But it's great during development, and after all your shipping app should not be crashing and burning anyway.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments