Funzioni che restituiscono "OK" o "messaggio di errore" al posto delle procedure

Question

Funzioni che restituiscono "OK" o "messaggio di errore" al posto delle procedure

#1 da (3 voti)

-2

Mi sono unito alla scrittura di un'applicazione di database multifunzione di medie dimensioni come co-lead. Attualmente ha circa 150 tabelle (e in crescita) e una funzionalità generale che puoi immaginare come ERP molto piccolo.

In molti punti del codice, le funzionalità che normalmente appartengono a procedure (intendo funzioni senza valore di ritorno) come DeleteAttachment o SaveRecord sono messe in funzione con il valore di ritorno che riporta il loro stato di uscita in stringa. Restituiscono "OK" in caso di successo o messaggi come "Deletion failed because ......." o "Insufficient privileges for ......." .

Alla fine, spesso all'utente finale viene presentato il messaggio che hanno fornito. Da un lato, questo è un meccanismo efficace di tracciamento di potenziali problemi. D'altra parte, non sono sicuro se dovrei incoraggiare questo approccio di scrivere la logica aziendale interna.

Capisco che non sia un ottimo modo per inserire problemi non fatali nelle eccezioni ( EInsufficientUserPrivileges , ERecordAlreadyExists ). Dovremmo attenerci all'attuale approccio o ce n'è un altro più adatto alle applicazioni che utilizzano molti controlli e logiche di business?

error-handling design-patterns exceptions erp

posta miroxlav 11.04.2014 - 12:55

fonte

1 risposta

Leggi altre domande sui tag error-handling design-patterns exceptions erp

Come si generano sfidanti puzzle diversi come quello del gioco Android AirLock [chiuso] Come mantenere il trade off tra il numero di colonne nelle operazioni table vs join? [chiuso]

score 3 · Accepted Answer

Per tracciare la linea tra le eccezioni e i valori di ritorno, proverei ad attenermi a quanto segue: - Ogni volta che un'istruzione rompe il flusso di esecuzione previsto, ci si aspetta che venga generato un errore. - Se la funzione prevista della procedura può avere risultati diversi, si vorrà lavorare con i valori di ritorno.

Negli esempi che stai affermando, sembra molto chiaro che l'istruzione prevista non viene eseguita. Messaggi di errore come "Eliminazione fallita" o "Privilegi insufficienti" finiscono con l'annullamento dell'azione. Pertanto, ti aspetteresti chiaramente che venisse generato un errore. In questo contesto, fatale è equivalente a "la tua istruzione non può essere eseguita". D'altra parte, un'eccezione non deve necessariamente essere fatale. Potresti gestirlo correttamente e procedere con altre istruzioni (altre eliminazioni, inserzioni o qualsiasi altra cosa da fare). Questo è ciò che puoi ottenere con un blocco catch.

Un'altra cosa: restituire una stringa con "OK" non è una buona pratica. Usa invece valori booleani. Ora di nuovo, se vuoi che i valori di ritorno siano "OK" o "Messaggio di errore", un booleano non ti permetterà di ottenerlo. Un'eccezione ti consentirà di inserire un messaggio di errore e qualsiasi dettaglio che desideri archiviare sull'errore che si è verificato. Ad esempio, se un utente non ha accesso, memorizza il nome utente, i privilegi che ha e il record a cui ha tentato di accedere in un'eccezione. Potresti quindi utilizzare queste informazioni mentre rilevi l'errore per generare un breve messaggio di errore per l'utente e un messaggio più dettagliato per il tuo log degli errori.