Quando scrivi i wrapper per le API come gestisci gli errori di utilizzo?

Pensa a wrapper vs adapter a bridge da un punto di vista del modello di progettazione. Potresti avere una nuova prospettiva e trovare la tua risposta da lì.

es. Adattatori e wrapper di Andy Kramek e molto altro su google.

Gran parte della risposta dipende dall'API che stai avvolgendo, dal pubblico di destinazione per il wrapping e dalla lingua che stai utilizzando. Se stai esponendo un'API scritta in una tecnologia particolare a una tecnologia diversa, ci sarebbe un valore nel risolvere alcuni dei problemi più comuni nella tecnologia avvolta. Ad esempio, .NET avvolge alcune API Win32, come CreateFile () per leggere un file. È abbastanza facile usare i parametri errati per CreateFile (), quindi se vuoi fare qualcosa di semplice come leggere un file di testo, c'è una funzione di utilità per ottenere solo quell'operazione, piuttosto che incapsulare ogni funzione con una versione avvolta.

Controllare i parametri di input per vuoti / nulli / fuori intervallo prima di chiamare l'API avvolta avrebbe valore, ma non se è a scapito delle prestazioni - meglio decifrare il problema quando la funzione incapsulata fallisce.

Le eccezioni, se disponibili nella tua lingua di wrapping, sarebbero appropriate per trasmettere errori al chiamante.

Non dovresti mai fidarti del tuo chiamante, che sta chiamando la tua API. È necessario implementare controlli rigorosi sugli input. E convalidare sempre l'oggetto richiesta prima di inviarlo ad ulteriore elaborazione. È possibile utilizzare l'approccio di dare un oggetto risposta al chiamante. Avere un campo di codice di risposta e descrizione della risposta. E puoi standardizzare questi codici di risposta per la tua applicazione.