Sintassi rapida do-try-catch

Provo a capire la nuova cosa di gestione degli errori in swift 2. Ecco cosa ho fatto: ho prima dichiarato un errore enum:

enum SandwichError: ErrorType {
    case NotMe
    case DoItYourself
}

E poi ho dichiarato un metodo che genera un errore (non un'eccezione gente. È un errore). Ecco quel metodo:

func makeMeSandwich(names: [String: String]) throws -> String {
    guard let sandwich = names["sandwich"] else {
        throw SandwichError.NotMe
    }

    return sandwich
}

Il problema è dal lato chiamante. Ecco il codice che chiama questo metodo:

let kitchen = ["sandwich": "ready", "breakfeast": "not ready"]

do {
    let sandwich = try makeMeSandwich(kitchen)
    print("i eat it \(sandwich)")
} catch SandwichError.NotMe {
    print("Not me error")
} catch SandwichError.DoItYourself {
    print("do it error")
}

Dopo il docompilatore di riga dice Errors thrown from here are not handled because the enclosing catch is not exhaustive. Ma secondo me è esaustivo perché ci sono solo due casi in SandwichErrorenum.

Per le normali istruzioni di commutazione, swift può capire che è esaustivo quando viene gestito ogni caso.

Vi sono due punti importanti nel modello di gestione degli errori di Swift 2: esaustività e resilienza. Insieme, si riducono alla tua do/ catchdichiarazione che deve cogliere ogni possibile errore, non solo quelli che sai di poter lanciare.

Si noti che non si dichiarano i tipi di errori che una funzione può generare, solo se si lancia affatto. È un tipo di problema zero-infinito: come qualcuno che definisce una funzione che gli altri (incluso il tuo sé futuro) possono usare, non devi fare in modo che ogni cliente della tua funzione si adatti ad ogni cambiamento nell'implementazione del tuo funzione, inclusi gli errori che può generare. Vuoi che il codice che chiama la tua funzione sia resistente a tale cambiamento.

Poiché la tua funzione non è in grado di dire che tipo di errori genera (o che potrebbe essere generato in futuro), i catchblocchi che li rilevano non conoscono i tipi di errori che potrebbero essere generati. Quindi, oltre a gestire i tipi di errore che conosci, devi gestire quelli che non hai con catchun'istruzione universale - in questo modo se la tua funzione cambia l'insieme di errori che genera in futuro, i chiamanti ne prenderanno comunque errori.

do {
    let sandwich = try makeMeSandwich(kitchen)
    print("i eat it \(sandwich)")
} catch SandwichError.NotMe {
    print("Not me error")
} catch SandwichError.DoItYourself {
    print("do it error")
} catch let error {
    print(error.localizedDescription)
}

Ma non fermiamoci qui. Pensa ancora a questa idea di resilienza. Nel modo in cui hai progettato il tuo sandwich, devi descrivere gli errori in ogni luogo in cui li usi. Ciò significa che ogni volta che cambi l'insieme dei casi di errore, devi cambiare ogni luogo che li utilizza ... non molto divertente.

L'idea alla base della definizione dei propri tipi di errore è quella di consentire di centralizzare cose del genere. Puoi definire un descriptionmetodo per i tuoi errori:

extension SandwichError: CustomStringConvertible {
    var description: String {
        switch self {
            case NotMe: return "Not me error"
            case DoItYourself: return "Try sudo"
        }
    }
}

E poi il tuo codice di gestione degli errori può chiedere al tuo tipo di errore di descriverlo - ora ogni posto in cui gestisci gli errori può usare lo stesso codice e gestire anche possibili casi di errore futuri.

do {
    let sandwich = try makeMeSandwich(kitchen)
    print("i eat it \(sandwich)")
} catch let error as SandwichError {
    print(error.description)
} catch {
    print("i dunno")
}

Questo apre anche la strada a tipi di errore (o estensioni su di essi) per supportare altri modi di segnalazione degli errori - ad esempio, potresti avere un'estensione sul tuo tipo di errore che sa come presentare un UIAlertControllerper segnalare l'errore a un utente iOS.

Sospetto che questo non sia ancora stato implementato correttamente. La Guida alla programmazione Swift sembra sicuramente implicare che il compilatore possa dedurre corrispondenze esaurienti "come un'istruzione switch". Non fa menzione della necessità di un generale catchper essere esaustivo.

Noterai anche che l'errore si trova sulla tryriga, non alla fine del blocco, ovvero ad un certo punto il compilatore sarà in grado di individuare quale tryistruzione nel blocco ha tipi di eccezione non gestiti.

La documentazione è un po 'ambigua. Ho sfogliato il video "Novità di Swift" e non ho trovato alcun indizio; Continuerò a provare.

Aggiornare:

Passiamo ora alla Beta 3 senza alcun suggerimento sull'inferenza ErrorType. Ora credo che se questo fosse mai stato pianificato (e penso ancora che lo fosse ad un certo punto), l'invio dinamico sulle estensioni del protocollo probabilmente lo ha ucciso.

Aggiornamento Beta 4:

Xcode 7b4 ha aggiunto il supporto per i commenti doc Throws:, che "dovrebbe essere usato per documentare quali errori possono essere generati e perché". Immagino che questo fornisca almeno un meccanismo per comunicare errori ai consumatori API. Chi ha bisogno di un sistema di tipi quando hai la documentazione!

Un altro aggiornamento:

Dopo aver trascorso un po 'di tempo a sperare ErrorTypenell'inferenza automatica e aver scoperto quali sarebbero i limiti di quel modello, ho cambiato idea: questo è ciò che spero invece Apple attui. Essenzialmente:

// allow us to do this:
func myFunction() throws -> Int

// or this:
func myFunction() throws CustomError -> Int

// but not this:
func myFunction() throws CustomErrorOne, CustomErrorTwo -> Int

Ancora un altro aggiornamento

La logica di gestione degli errori di Apple è ora disponibile qui . Ci sono state anche alcune discussioni interessanti sulla mailing list di rapida evoluzione . In sostanza, John McCall si oppone agli errori di battitura perché ritiene che la maggior parte delle biblioteche finirà comunque per includere un caso di errore generico e che è improbabile che errori di battitura aggiungano molto al codice a parte il bollettino (ha usato il termine "bluff aspirazionale"). Chris Lattner ha dichiarato di essere aperto agli errori di battitura in Swift 3 se funziona con il modello di resilienza.

Swift teme che l'istruzione case non copra tutti i casi, per risolverlo è necessario creare un caso predefinito:

do {
    let sandwich = try makeMeSandwich(kitchen)
    print("i eat it \(sandwich)")
} catch SandwichError.NotMe {
    print("Not me error")
} catch SandwichError.DoItYourself {
    print("do it error")
} catch Default {
    print("Another Error")
}

Sono stato anche deluso dalla mancanza di tipo che una funzione può lanciare, ma ora lo capisco grazie a @rickster e lo riassumo in questo modo: diciamo che potremmo specificare il tipo che una funzione genera, avremmo qualcosa del genere:

enum MyError: ErrorType { case ErrorA, ErrorB }

func myFunctionThatThrows() throws MyError { ...throw .ErrorA...throw .ErrorB... }

do {
    try myFunctionThatThrows()
}
case .ErrorA { ... }
case .ErrorB { ... }

Il problema è che anche se non cambiamo nulla in myFunctionThatThrows, se aggiungiamo un caso di errore a MyError:

enum MyError: ErrorType { case ErrorA, ErrorB, ErrorC }

siamo fregati perché il nostro do / try / catch non è più esaustivo, così come qualsiasi altro posto in cui abbiamo chiamato funzioni che generano MyError

enum NumberError: Error {
  case NegativeNumber(number: Int)
  case ZeroNumber
  case OddNumber(number: Int)
}

extension NumberError: CustomStringConvertible {
         var description: String {
         switch self {
             case .NegativeNumber(let number):
                 return "Negative number \(number) is Passed."
             case .OddNumber(let number):
                return "Odd number \(number) is Passed."
             case .ZeroNumber:
                return "Zero is Passed."
      }
   }
}

 func validateEvenNumber(_ number: Int) throws ->Int {
     if number == 0 {
        throw NumberError.ZeroNumber
     } else if number < 0 {
        throw NumberError.NegativeNumber(number: number)
     } else if number % 2 == 1 {
         throw NumberError.OddNumber(number: number)
     }
    return number
}

Ora convalida il numero:

 do {
     let number = try validateEvenNumber(0)
     print("Valid Even Number: \(number)")
  } catch let error as NumberError {
     print(error.description)
  }

Crea enum in questo modo:

//Error Handling in swift
enum spendingError : Error{
case minus
case limit
}

Crea un metodo come:

 func calculateSpending(morningSpending:Double,eveningSpending:Double) throws ->Double{
if morningSpending < 0 || eveningSpending < 0{
    throw spendingError.minus
}
if (morningSpending + eveningSpending) > 100{
    throw spendingError.limit
}
return morningSpending + eveningSpending
}

Ora controlla l'errore c'è o no e gestiscilo:

do{
try calculateSpending(morningSpending: 60, eveningSpending: 50)
} catch spendingError.minus{
print("This is not possible...")
} catch spendingError.limit{
print("Limit reached...")
}