Can we get a "try?" as a more lenient "try!"?

You can define your own control structure:

func ignorethrow(@noescape block: () throws -> Void) {
    do {
        try block()
    } catch {
    }
}

which you can then use like this:

ignorethrow { try fileManager.removeFileAtPath(cachePath1) }
ignorethrow { try fileManager.removeFileAtPath(cachePath2) }
ignorethrow { try fileManager.removeFileAtPath(cachePath3) }

Converting the error to an optional is probably not ideal, since the reason for throwing an error (or in the Objective-C case, returning an error) is to be more detailed in the error reporting.

EDIT: added @noescape to make it more convenient if the code references self implictly.

We also have all these annoying catch {} everywhere when using NSFileManager.

What about this solution?

extension NSFileManager {
     func tryRemoveItemAtPath(path: String) -> Bool {
          do {
               try removeItemAtPath(path)
               return true
          }
          catch {
               return false
          }
     }
}

And then:

fileManager.tryRemoveItemAtPath(cachePath1)
fileManager.tryRemoveItemAtPath(cachePath2)
fileManager.tryRemoveItemAtPath(cachePath3)

+1

The suggested work-arounds are fine, but this is such a common use case that it should be streamlined.

Yes, I have also thought about the need for an operator "try?". Just did not comment

It's not crazy to me, it is to even obvious: Not all errors need to be addressed in all contexts.

And also if "try?" is be implemented, it would be possible to disable empty catch ("catch {}") for safety and readability.

The point is, you SHOULD care. You should be striving to write error free code

not ignoring errors. Anything less is just sloppy at best, lazy at worse.

I would posit that Swift is correct as it is, but the FileManager API is what needs to be changed.

It sounds like we need `NSFileManager { func ifExistsDeleteFile(file:string) -> Void` or something

As shown at WWDC, Apple divides errors into 3 categories:

// category 1
if let a = Int("1") {

}

// category 2
enum DataError : ErrorType {
    case ParserError
}
extension String {
    func toInt() throws -> Int {
        guard let a = Int("1") else {
            throw DataError.ParserError;
        }
        return a;
    }
}
do {
let a = try "1".toInt()
//...
} catch {
//...
}

// category 3
let a = Int("a")!
print("This string number is: \(a)")

At the same time, we have the ability to do the reverse:

//1
extension Array {
    subscript (s index: Int) -> T? {
        return self.indices ~= index ? self[index] : nil
    }
}
//2
enum DataError : ErrorType {
    case OutOfBounds
}
extension Array {
    func atIndex(index: Int) throws -> T {
        guard let response = self[s: index] else {
            throw DataError.OutOfBounds
        }
        return response
    }
}
let arr = [1,2,3]
let c = arr[s: 5]; // possible error category 1
let b = try arr.atIndex(6); // possible error category 2
let a = arr[7]; // possible error category 3

The ability to change how important an error is has always been on the developer's responsibility, is an explicit agreement between him and the compiler because it formally established the functions for such.

We already have the try! operator to promote some code made on "category 2" to 3 code. But we dont have to make the category 2 to 1. Its possible make some hacks, but is better make this built in on the language.

If we look some samples codes from Apple, scattered throughout developer library we will see that in several places when they pass nil as the argument to a call NSError function, and this is not anything crazy: I repeat, some errors messages are irrelevant in some applications.

And in several cases we have to deal with a developer arbitrary decision to provide a more detailed response to a problem:

// Swift 1.2
if let unarchiveJSON = NSJSONSerialization.JSONObjectWithData(data, options: NSJSONReadingOptions.AllowFragments, error: nil) as? [String:NSObject] {
   // This is all i need, no detail is important to me in this app, in another app maybe will.
}

But now:

var unarchiveJSON:[String:NSObject]?
do {
    unarchiveJSON = try NSJSONSerialization.JSONObjectWithData(data, options: NSJSONReadingOptions.AllowFragments) as? [String:NSObject]
} catch { }
if let unarchiveJSON = unarchiveJSON {
// ...
}

Using "try?"

if let unarchiveJSON = try? NSJSONSerialization.JSONObjectWithData(data, options: NSJSONReadingOptions.AllowFragments) as? [String:NSObject] {
   // This is all i need in this particular case example.
}

The try? operator is valid in this context as any other explicit treatment. Is me, developer saying: In this context, that error is not of category 2 but category 1.

This new proposed operator, will simply normalize the inevitable fact that in many cases some errors messages are not important, using a unified, clear syntax for everyone. And it will also, maybe, help to handle with the case "catch {}" making this a compilation error (error-prone). Optionals result, is, in that way, some kind of error handler! I'm not avoid the error, just making another treatment, with less boilerplate.

And most importantly: Will encourage more people to detail their errors using "throws" without fear of creating problems for those who use your code.

With try? operator, Int(someString) could throws some error and this:

if let a = try? Int("1") {
//...
}

Will be used for people who dont care why this Int parser fail, like i don't care why NSJSONSerialization fail above.

Well, it looks like they have dealt with this simply by converting checkResourceIsReachable back into a non-throwing method; now it's once again checkResourceIsReachableAndReturnError. Still no fix for use cases like the OP's, unfortunately.

The one issue with 'try?' that I see is that the '!' family indicates code may be making unsafe assumptions in the case of code review. A try? may actually be an unsafe assumption - that we can ignore the error value returned from a method; that the error won't cascade further down the line making debugging hellish. It's just not an unsafe assumption that immediately results in the app asserting/crashing.

There are cases where you should be able to safely ignore an error, but I fear 'try?' makes it way too easy to ignore errors that the developer should actually be acting on. Some sort of standard library 'ignorethrow' @noescape function may be more appropriate

Looks like "try?" has been added to Beta 6:

http://adcdownload.apple.com/Developer_Tools/Xcode_7_beta_6/Xcode_7_beta_6_Release_Notes.pdf