lanciare, restituire o errno?

Question

Sto creando un sistema. Quello che voglio sapere è se un messaggio non è supportato cosa dovrebbe fare? dovrei lanciare dicendo msg non supportato? dovrei restituire 0 o -1? o dovrei impostare un errno (base- > errno_). Alcuni messaggi non mi importerebbe se ci fosse un errore (come setBorderColour). Altri vorrei (aggiungere testo o forse salvare se creo un cmd di salvataggio).

Voglio sapere qual è il metodo migliore per 1) la codifica rapida 2) il debug 3) l'estensione e la manutenzione. Potrei effettuare il debug in terza posizione, è difficile eseguire il debug di ATM ma questo è perché c'è un sacco di codice mancante che non ho compilato. I bug reali non sono difficili da correggere. Qual è il modo migliore per far sapere all'utente che c'è un errore?

Il sistema funziona in questo modo ma non è esattamente lo stesso. Questo è in stile C e mycode ha un sacco di funzioni incorporate che racchiudono settext (const char * text) {in msg (this, esettext, text)

Base base2, base;
base = get_root();
base2 = msg(base, create, BASE_TYPE);
msg(base2, setText, "my text");
const char *p = (const char *)msg(base2, getText);

Answer 1

In genere, se è C ++, preferisci le eccezioni, a meno che le prestazioni non siano critiche o a meno che tu non stia eseguendo un ambiente (ad esempio una piattaforma integrata) che non supporta le eccezioni. Le eccezioni sono di gran lunga la scelta migliore per il debug perché sono molto evidenti quando si verificano e vengono ignorate. Inoltre, le eccezioni sono auto-documentate. Hanno il loro nome di tipo e di solito un messaggio contenuto che spiega l'errore. Codici di ritorno ed errno richiedono definizioni di codice separate e una sorta di modo fuori banda di comunicare il significato dei codici in un determinato contesto (ad esempio pagine man, commenti).

Per la codifica rapida, i codici di ritorno sono probabilmente più facili poiché non implicano potenzialmente la definizione dei propri tipi di eccezione e spesso il codice di controllo degli errori non è così dettagliato come con le eccezioni. Ma ovviamente il grosso rischio è che è molto più facile ignorare silenziosamente i codici di ritorno degli errori, portando a problemi che potrebbero non essere notati fino a quando non si verificano, rendendo il debug e la manutenzione un incubo.

Cerca di evitare di usare errno, dato che è molto soggetto a errori. È globale, quindi non si sa mai chi lo sta ripristinando ed è sicuramente non sicuro dal thread.

Modifica: ho appena capito che intendevi una variabile membro errno e non l'errno in stile C. È meglio in quanto non è globale, ma hai ancora bisogno di costrutti aggiuntivi per renderlo sicuro (se la tua app è multi-thread) e mantiene tutti i problemi di un codice di ritorno.

Answer 2

La restituzione di un codice di errore richiede disciplina poiché il codice di errore deve essere verificato in modo esplicito e quindi trasmesso. Abbiamo scritto un grande sistema basato su C che utilizzava questo approccio e ci è voluto un po 'di tempo per rimuovere tutto il "perso" errori. Alla fine abbiamo sviluppato alcune tecniche per rilevare questo problema (come la memorizzazione del codice di errore in una posizione globale del thread e il controllo al livello più alto per verificare che il codice di errore restituito corrispondesse al codice di errore salvato).

La gestione delle eccezioni è più facile da codificare rapidamente perché se stai scrivendo un codice e non sei sicuro di come gestire l'errore, puoi semplicemente lasciarlo propagare verso l'alto (supponendo che non stai usando Java dove devi affrontare eccezioni controllate). È meglio per il debug perché è possibile ottenere una traccia dello stack di dove si è verificata l'eccezione (e perché è possibile creare gestori di eccezioni di livello superiore per rilevare i problemi che avrebbero dovuto essere rilevati altrove). È meglio per il mantenimento perché se hai fatto le cose bene, sarai avvisato del problema più velocemente.

Tuttavia, ci sono alcuni problemi di progettazione con la gestione delle eccezioni e, se sbagli, peggiorerai. In breve, se stai scrivendo un codice che non sai come gestire un'eccezione, dovresti lasciarlo propagare. Troppi programmatori intrappolano gli errori solo per convertire l'eccezione e quindi riproporla, generando un codice di eccezione spaghetti che a volte perde informazioni sulla causa originale del problema. Ciò presuppone che tu abbia gestori di eccezioni al livello superiore (punti di ingresso).

Answer 3

Personalmente quando si tratta di output grafico, sento che un fallimento silenzioso va bene. Rende solo la tua foto sbagliata.

Gli errori grafici sono comunque super facili da individuare.

Answer 4

Personalmente, aggiungerei un errno alla tua struttura di Base se è pura "C". Se questo è C ++, creerei un'eccezione.

Dipende da quanto siano fatali questi errori. L'utente deve davvero vedere l'errore o è per l'edificazione di altri sviluppatori?

Per manutenibilità è necessario documentare chiaramente gli errori che possono verificarsi e includere chiari esempi di gestione degli errori.