Diversi tipi di eccezioni controllate - Garantire di lanciare solo X

4

È una posizione ampiamente condivisa che controllare le eccezioni come implementate in Java è una cattiva idea. Se contrassegni un metodo come lancio, il codice chiamante deve prendere l'eccezione o essere contrassegnato come lancio. Per questo motivo, si dice che le specifiche delle eccezioni sono contagiose. Di conseguenza, vengono rimossi da C ++ (ad eccezione di noexcept ).

Mi chiedo se è possibile implementare un diverso tipo di eccezioni controllate. Invece di "Il chiamante deve catturare questo" , significherebbe "Lo butterò sempre" .

L'ambito di chiamata non dovrà essere modificato affatto. Mi aiuta come scrittore della funzione chiamata a capire che cosa potrei lanciare, se decido di aggiungere un'annotazione. Permetterebbe anche di mostrare le eventuali eccezioni durante il completamento del codice. Potrei immaginare eccezioni mortali speciali saranno sempre consentite, come OutOfMemoryException o Python KeyboardInterrupt .

Ad esempio (pseudocodice):

// simple case (could actually be inferred)
string lookupString(string key) throws only KeyError {
    return m_map[key];
}

// complex failing example
string readFromFile(string filename) throws IndexError {
    File f = File.Open(filename);
    return f.readline();
}
// -> Compilation error:
// File.Open may cause IOError, but readFromFile guarantees to only throw IndexError
// (optional:)
// readFromFile suggests it will throw IndexError,
// but no operation in it may possibly throw IndexError.

Se non fornisci alcuna specifica, ti suggerirei di consentire qualsiasi eccezione ( throw Throwable ). Immagino che aggiungere questa funzione a una lingua esistente e questa sarebbe l'unica opzione compatibile con le versioni precedenti. Per una nuova lingua, pensi a un diverso predefinito.

Per gestire il codice legacy (in una libreria esterna), potrebbe esserci un modo per dire al compilatore che una determinata funzione o un blocco di codice può solo generare alcune eccezioni. Concettualmente un po 'come unsafe in C #:

I swear throws only ParseError {
    return JSON.parse(json);
}

Non sono a conoscenza di alcun linguaggio che implementa questo tipo più debole di eccezioni controllate. Mi sembra che avrebbero molti vantaggi, ma senza gli svantaggi delle eccezioni controllate di Java. Ci sono motivi per cui questa idea non funzionerebbe? Qualunque lingua ha implementato con successo questa funzione, o ha provato e fallito?

(Nota, per favore non leggere questo come una domanda alla ricerca di una raccomandazione di lingua e poi chiuderla.Questa è una domanda sulla progettazione della lingua, vorrei capire meglio i vantaggi e gli svantaggi di questo approccio.Possibili risposte che potrei Immagino sarebbe: "Sì, questo è stato tentato nel linguaggio XY, ma non funziona molto bene a causa dell'interazione con i generici." oppure "No, questo non è mai stato implementato, ma è una grande idea. > < argomento teorico della lingua > , questo può essere implementato in un sistema di tipi di suono. Guarda questo lavoro di Foobar per maggiori informazioni. ")

    
posta jdm 29.05.2017 - 14:14
fonte

0 risposte

Leggi altre domande sui tag