The “fine print” here is that SoundFileView:read does not access the buffer’s contents. It asks the object stored under soundfile what is its path, and then reads from disk. If you’ve read the buffer from disk, then the Buffer object has a path – so Buffers can sort of substitute for SoundFiles here, but it isn’t using any of the other Buffer variables such as numChannels – readChannel will have zero effect on SoundFileView’s behavior.
I don’t see any built-in SoundFileView method to de-interleave channels, but you can load and manipulate the contents yourself.
In this context, it’s a “just in case” policy – you want the file handle to be closed whether there’s an exception or not. It “shouldn’t” come to that but if it does, it’s covered. For that reason, I’ve been wrapping file access in protect for some time.
There’s also try which can decide whether to swallow the exception or re-throw it. (The return value from the try method is not always reliable – there’s a bug filed somewhere about that – workaround is to structure the usage so that you don’t need the return value.)