Difference in placement of "try" keyword

Question

I have a global variable of audio player. What's the difference between placing try word before the variable initialization

do{
   try audioPlayer = AVAudioPlayer(contentsOf: audioURL)
}catch {}

and placing try before calling the constructor

do{
   audioPlayer = try AVAudioPlayer(contentsOf: audioURL)
}catch {}

Of course two cases above haven't any compilation errors. Thanks

Answer 1

There is no practical difference. As said by the language guide (emphasis mine):

When the expression on the left hand side of a binary operator is marked with try, try?, or try!, that operator applies to the whole binary expression. That said, you can use parentheses to be explicit about the scope of the operator’s application.

// try applies to both function calls
sum = try someThrowingFunction() + anotherThrowingFunction()

// try applies to both function calls
sum = try (someThrowingFunction() + anotherThrowingFunction()) 

// Error: try applies only to the first function call
sum = (try someThrowingFunction()) + anotherThrowingFunction()

Just like +, assignment is also a binary operator. Therefore, when you say

do{
   try audioPlayer = AVAudioPlayer(contentsOf: audioURL)
}catch {}

The try applies to both expressions audioPlayer and AVAudioPlayer(contentsOf: audioURL). The lone expression audioPlayer cannot possibly throw an error here – therefore the try in this case only applies to the call to AVAudioPlayer's init(contentsOf:), which can throw.

The derivation of the grammar for this is:

//           "try"          "audioPlayer"     "= AVAudioPlayer(contentsOf: audioURL)"
expression → try-operator­opt ­prefix-expression ­binary-expressions­opt

prefix-expression → prefix-operator­opt ­postfix-expression
postfix-expression → primary-expression­
primary-expression → identifier­ generic-argument-clause­opt
identifier­ → // matches "audioPlayer" (I'm not going to fully derive this bit further)

binary-expressions → binary-expression ­binary-expressions­opt
binary-expression → assignment-operator ­try-operator­opt­ prefix-expression
prefix-expression → prefix-operator­opt postfix-expression
postfix-expression → initializer-expression­ // matches AVAudioPlayer(contentsOf: audioURL)

When you say

do{
   audioPlayer = try AVAudioPlayer(contentsOf: audioURL)
}catch {}

You're using the fact that the assignment expression has the grammar of:

binary-expression → assignment-operator ­try-operator­opt ­prefix-expression­

As you can see, the try-operator can also appear on the right hand side of the operator here, and therefore will apply to the prefix-expression – which in this case is AVAudioPlayer.init(contentsOf:).

So in both cases, you're catching the error potentially thrown from AVAudioPlayer.init(contentsOf:). The first example just includes the possibility of an error being thrown from the expression on the left hand side of the operator, which it cannot possibly do.

Use whichever you feel more comfortable with – my personal preference, and the option which is more consistent with the placement of try in other places in the language, is to put the try on the right-hand side.

Answer 2

In my view, the fact that this compiles is kind of a bug:

try audioPlayer = AVAudioPlayer(contentsOf: audioURL)

Basically, you're doing something you shouldn't do, and you're just lucky that it slides past the compiler here. Consider, as a counterexample, what would happen if audioPlayer were being declared here:

try let audioPlayer = AVAudioPlayer(contentsOf: audioURL) // error

That doesn't compile, and the Fix-It correctly moves the try to where it belongs:

let audioPlayer = try AVAudioPlayer(contentsOf: audioURL)

The rule that I recommend following, therefore, is that you should use try placement correctly — it modifies the method call that can throw. It may sometimes work for an assignment as a whole, but not always, and it's a bad habit to get into.