Ok to force unwrap tableView.indexPath?

Question

I have a segue from a table view controller to another view controller. Inside the method prepare(for: sender) I need to get the indexPath of the cell that triggered the segue. Is it Ok to force unwrap the index path in this case? After all the prepare() method was triggered by tapping on a table row so it seems I can make the assumption that 'sender' contains a reference to a valid object yes?

override func prepare(for segue: UIStoryboardSegue, sender: Any?) { 
  if segue.identifier == "TheCorrectSegue" { 
    let indexPath = tableView.indexPath(for: sender as! UITableViewCell)! <-- is this OK? 
}}

Swift

1.4k

Posted by

ehmjaysee

Reply

Add a Comment

Answer 1

why not test it :

if let indexPath = tableView.indexPath(for: sender as! UITableViewCell) {

}

Posted by

Claude31

Add a Comment

Answer 2

One simple advice, NEVER use forced-something(`!`, `as!` or `try!`) when you are not 100%-sure about it:

            if
                let cell = sender as? UITableViewCell,
                let indexPath = tableView.indexPath(for: cell)
            {
                //Do what you need to do...
            } else {
                print("Something is wrong...")
            }

Posted by

OOPer

Add a Comment

Answer 3

Or more elegantly:

guard let cell = sender as? UITableViewCell else { print("No cell"); return }
guard let indexPath = tableView.indexPath(for: cell) else { print("No indexPath"); return }

Thus there is no indenting and the handling of errors occurs where the error occurs

Posted by

logistes

Add a Comment

Answer 4

One simple advice, NEVER use forced-something(
!
,
as!
or
try!
) when you are not 100%-sure about it:

I have a very different take on this. My general rule is Force stuff when there’s no reasonable way to handle the error. In this case, what are you going to do in the “something is wrong” branch? There’s no reasonably way to explain to the user that either your app or the iOS frameworks have got into such a state that you can’t continue. It’s better, IMO, to force the value and, if things go wrong, get a clear and reliable crash report. That will make it easier to find and fix these problems in the beta cycle, before they escape into the real world.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Posted by

eskimo

Add a Comment

Answer 5

eskimo thanks for the suggestion. This was a new way to think about the unwrapping debate I had not considered. After thinking about my question I realized the real question I was trying to ask was this: Was this a case where I can rely on the iOS framework to send me valid data? Or do I need to use defensive programming here? This kind of situation seems to arise quite often for me and I wonder how other people deal with it. Apple documentation will not answer this question I think. For my case in this thread I guess I would want to force a crash if prepare() was called with invalid data, as long as I was certain I would get a core dump that has enough info to debug the problem. That is the next thing I need to learn how to do.

Posted by

ehmjaysee

Add a Comment

Answer 6

Was this a case where I can rely on the iOS framework to send me valid data?

Yeah, that’s exactly the right question to ask IMO.

Apple documentation will not answer this question I think.

Indeed. However the Error Handling Rationale and Proposal is a really good resource here, especially the Kinds of error section.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Posted by

eskimo

Add a Comment

Ok to force unwrap tableView.indexPath?

Replies