I'm using the GameplayKit entity component system to develop a game.
I have a number of GKComponent. Most of the instance functions require that self.entity is not nil, but it is an optional, as a component may be initialised before being attached to an entity.
If I "do things properly", I understand I should use guard (or if) to check that self.entity is not nil, for each function where I require it. This adds a chunk of extra code for each function, and in addition a function may require the entity has specific components to function.
Problem statement:
For some functions in a GKComponent, I want to specify that the function requires self.entity is not nil, and has some specific components, without needing a number of guard or if statements which bulks up my code.
Things I've tried:
I tried creating an extension to GKComponent.
The extension contains a function which throws an error if the entity is nil, returns true if it is not nil.
import Foundation
import GameplayKit
extension GKComponent {
enum ComponentExtensionError: Error {
case hasNoEntity
}
func requiresEntity() throws -> Bool {
if (self.entity != nil) {
return true
} else {
throw ComponentExtensionError.hasNoEntity
}
}
}
GKComponent function:
func setTileWalls () {
try? self.requiresEntity()
# Some stuff
}
This compiles, but doesn't solve my problem, as I still have to access the entity as self.entity?.somefunc().
I figured now I know that self.entity is not nil, I could proceed to set it as unwrapped...
func setTileWalls () {
try? self.requiresEntity()
self.entity = self.entity!
# Some stuff
}
But alas, you cannot SET self.entity.
I considered I could in stead modify the extension to return the entity, and then do something like...
func stTileWalls () {
guard let entity = self.requiresEntity() else { throw }
}
but then I'd need to modify each functions code to use entity rather than self.entity. I don't feel like this is optimal solution, but maybe an acceptable one.
My ideal solution would be to be able to call a function which checks that self has an entity, and some components, making them non optional for the scope, and throwing an error if any are nil.
Why? I'm frustrated by entity and any component always being optional (when I know it shouldn't be). If I understand correctly, "doing things properly" requires that I guard and throw (or return maybe?). Syntactically I feel it looks ugly and I feel like I'm missing something in terms of fixing this in an elegent way with Swift.
There is no easy solution to solve this issue if you want a safe solution that requires less boilerplate code than unwrapping an optional.
Throwing an error instead of returning nil is definitely a bad idea, since handling an error requires even more boilerplate code than safely unwrapping an optional.
You cannot override existing variables types, so you cannot make GKComponent.entity non-optional either.
Use guard statements for optional binding, that way you can minimise the boilerplate code for unwrapping the value.
Related
I'm trying to understand Swift error handling better, but I can't find a specific answer to this question online. I have an application that uses optionals a lot to do error handling. For example, here's a snippet of code from my app:
if let winnerName = gameApiResponse.winner {
guard let gameFromApi = GameFromApi(id: gameApiResponse.id, contestantsNames: gameApiResponse.contestants, winnerName: winnerName, confidence: 50, conferencesNames: conferenceNamesInGame, week: gameApiResponse.week) else {
os_log("Could not unwrap new game object in loadGames(gameApiResponses:) in DataModelManager", type: .debug)
return GameFromApi()
}
return gameFromApi
} else {
guard let gameFromApi = GameFromApi(id: gameApiResponse.id, contestantsNames: gameApiResponse.contestants, winnerName: nil, confidence: 50, conferencesNames: conferenceNamesInGame, week: gameApiResponse.week) else {
os_log("Could not unwrap new game object in loadGames(gameApiResponses:) in DataModelManager", type: .debug)
return GameFromApi()
}
return gameFromApi
}
GameFromApi is a class that has a failable initializer and a default, non-failable initializer (with no parameters). If the regular initializer fails, I call the default initializer and just give this function back a "blank" GameFromApi object that has default values. But I'm mostly using this default initializer to indicate that something went wrong, which feels bad. Plus, I feel like I'm overusing optionals to do error handling in cases when the reason for the failure could be many different things.
What's the litmus test for when to use optionals to indicate an error, and when to use exceptions?
You should throw errors whenever details of the error are available, and they could be used in some way to recover the error.
For example, opening a file on the filesystem might fail because of an incorrect path, a permission error, or the file being the wrong type (e.g. a folder). A thrown error might include this information, but it won't really help, because there wouldn't be much your application could do with that information to recover from the error.
In your case, I think optionals are a good choice. However, you shouldn't repeat yourself:
guard let gameFromApi = GameFromApi(
id: gameApiResponse.id,
contestantsNames: gameApiResponse.contestants,
winnerName: gameApiResponse.winner,
confidence: 50,
conferencesNames: conferenceNamesInGame,
week: gameApiResponse.week
) else {
os_log("Could not unwrap new game object in loadGames(gameApiResponses:) in DataModelManager", type: .debug)
return GameFromApi()
}
return gameFromApi
I'm writing a utility function which takes a parameter and always returns a valid non-nil result (notice the returned value is not optional because the possible parameters are all actually hardcoded and valid, so I know the function cannot fail):
func myFunction(param: String) -> NonTrivialObject {...}
Now, during development I want to experiment with possible parameters and, should I make a mistake, I want the function to throw an exception and just crash. I don't want or need to throw Swift errors or catch them, I want to hard-crash and fix the parameter immediately. In Objective C I would just use NSParameterAssert() or do something along these lines:
guard let validatedParam = param where param != nil else {
NSException(...).raise()
return nil
}
// do the actual work and return a non-optional result
However, I cannot return nil because the result is not an optional. Is there a way to somehow tell the compiler that it doesn't need to bother returning anything from the function after an exception is thrown? Or am I doomed to litter my code with unwrapping optionals or try! statements or to return a dummy object just to make the compiler pleased?
You can use Swift assert(_:_file:line:) function as follows
assert(some condition, "Message to display if condition is false (optional)" )
If the condition is verified the app will continue running, otherwise it will terminate
An optional may contain nil, but Swift syntax forces you to safely deal with it using the ? syntax to indicate to the compiler you understand the behavior and will handle it safely.
You can define the function to be a throwing function:
func foo(param: String) throws -> NonTrivialObject {
guard param != nil else {
throw SomeErrorEnum.NilFound
}
doStuff(...)
}
The error enum needs to conform to the ErrorType protocol. The function call is now able to catch errors like this:
do {
try foo(param)
} catch SomeErrorEnum.NilFound {
print("Found nil")
}
In this way the function returns a non-optional but can also throw errors. For more information see: https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html
I'm very new to swift, but proficient in other languages like Java, JavaScript, C, ... I'm lost with Swift syntax when it comes to create expressions. Look at this basic example where I just try to find out if one string is contained into another by calling String.rangeOfString that returns an Optional Range (Range?)
This works as expected:
let LEXEMA:String="http://"
let longUrl:String="http://badgirls.many/picture.png"
let range=longUrl.rangeOfString(LEXEMA);
if (range? != nil) {
// blah
}
Now I'm trying to combine the expression inside the if, something like:
if (longUrl.rangeOfString(LEXEMA)? !=nil) {
// blah
}
But I always get syntax errors, the above yields a "Expected Separator" and can't understand why. Done some more tests:
if (absolutePath.rangeOfString(URL_LEXEMA) !=nil) { }
Expected Separator before "!"
if absolutePath.rangeOfString(URL_LEXEMA) !=nil { }
Braced block of statements is an unused closure
What am I doing wrong?
If you’re coming from other like Java, you might be thinking of optionals like pointers/references, and so used to equating them to nil and if non-nil, using them. But this is probably going to lead to more confusion. Instead, think of them like a container for a possible result, that you need to unwrap to use. if let combines the test and unwrapping operation.
With this in mind, here’s how you could adapt your code:
let LEXEMA: String="http://"
let longUrl: String="http://badgirls.many/picture.png"
if let range = longUrl.rangeOfString(LEXEMA) {
// use range, which will be the unwrapped non-optional range
}
else {
// no such range, perhaps log an error if this shouldn’t happen
}
Note, that ? suffixing behaviour you were using changes in Swift 1.2 so even the code in your question that compiles in 1.1 won’t in 1.2.
It’s possible that sometimes you are whether there was a value returned, but you don’t actually need that value, just to know it wasn’t nil. In that case, you can compare the value to nil without the let:
if longUrl.rangeOfString(LEXEMA) != nil {
// there was a value, but you don't care what that value was
}
That said, the above is probably better expressed as:
if longUrl.hasPrefix(LEXEMA) { }
For starters:
You don't need parenthesis with if statements unless you have nested parenthetical subexpressions that require it.
You don't need to specify the type on the left side of the = of a let or var declaration if Swift can figure it out from the right side of the =. Very often Swift can figure it out, and you can tell that Swift can figure it out, so you can avoid that redundant clutter.
You do need to specify the type if Swift cannot figure out the type from
the right side. Example:
For example, consider the following lines:
let LEXEMA = "http://"
let longUrl = "http://badgirls.many/picture.png"
Swift can figure out that they're strings.
Similarly for this function or class that returns a UIView:
var myView = ViewReturningClassOrFunc()
Consider this:
#IBOutlet var myView : UIView!
In the above line, Swift cannot figure out ahead of time it will be assigned a UIView, so you have to provide the type. By providing a ! at the end you've made it an implicitly unwrapped optional. That means, like ?, you're indicating that it can be nil, but that you are confident it will never be nil at the time you access it, so Swift won't require you to put a ! after it when you reference it. That trick is a time saver and big convenience.
You should NOT add the ? to the line:
if (longUrl.rangeOfString(URL_LEXEMA) !=nil) {
As another answer pointed out, you're missing the let.
if let longUrl.rangeOfString(URL_LEXEMA) {
println("What do I win? :-)")
}
swift is case sensitive language. you need to check about whitespaces as well
if longUrl.rangeOfString(LEXEMA) != nil {
//your condition
}
there should be space between statement != nil
Just add a space between != and nil like:
if longUrl.rangeOfString(LEXEMA) != nil {
// blah
}
I tested your code in playground, an error of Expected ',' separator reported.
And do not forget the rules that 1s and 0s and Airspeed Velocity said.
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.
I'd rather write this as
func giveMeAThing() -> Thing! {
if possibleErrorCase() {
crashAndBurn() // I assume this will not return anyhow
}
return createAThingForSure()
}
but that's likely just a question of taste.
You don't need an implicitly unwrapped optional since you don't expect the second case to return any value.
As commenters noted, use fatalError in the fail case.
I'm writing an application Bluetooth-controlled keynote remote. This will be using AppleScript to control Keynote based on interactions with the CoreBluetooth framework.
Consider this class, which requires the use of an optional OSALanguage initializer.
class KeynoteController {
let applescriptLanguage: OSALanguage
init?() {
if let applescriptLanguage = OSALanguage(forName: "AppleScript") {
self.applescriptLanguage = applescriptLanguage
} else {
return nil // Compile error on this line
}
}
}
In this example, I want to fail initializing my KeynoteController if there's no OSALanguage named "AppleScript" (admittedly unlikely, but good design). However, I can't return from my initializer until all stored properties are populated.
I could make applescriptLanguage an optional, but since it's non optional and constant if initialization succeeds, this seems like a hack.
What's the correct way to design this?
The problem seems to come from trying to make applescriptLanguage a non-optional. The compiler wants it to be assigned a value, even if the object is failing initialization.
Fix it by making it optional property (implicitly unwrapped because it should never actually be nil after initialization).
let applescriptLanguage: OSALanguage!
This seems like a compiler error to me, but I have no idea what's going on under the hood.
Alternatively, you could temporarily assign it to a dummy value in the else block. This adds extra initialization time and memory allocation, so probably not the best idea, but it'll work if you really want to have the property be non-optional.
} else {
self.applescriptLanguage = OSALanguage()
return nil
}