Le restrizioni di sicurezza dovrebbero rendere un servizio nullo o generare un'eccezione? [chiuso]

Sono un po 'in disaccordo con uno sviluppatore più esperto su questo problema e mi chiedo cosa ne pensano gli altri; il nostro ambiente è Java, EJB 3, servizi, ecc.

Il codice che ho scritto chiama un servizio per ottenere cose e creare cose. Il problema che ho riscontrato è che ho ricevuto eccezioni con puntatore null che non avevano senso. Ad esempio, quando chiedo al servizio di creare un oggetto, ottengo indietro nulla; quando provo a cercare un oggetto con un ID valido noto, ottengo indietro. Ho trascorso un po 'di tempo a cercare di capire cosa c'era di sbagliato nel mio codice; dal momento che sono meno esperto, di solito presumo di aver fatto qualcosa di sbagliato, ma si scopre che la ragione per i rendimenti nulli è stata la sicurezza. Se l'entità utente che utilizza il mio servizio non disponeva delle autorizzazioni giuste per il servizio di destinazione, restituisce semplicemente null. La maggior parte degli altri servizi qui non sono documentati molto bene, quindi apparentemente questo è solo qualcosa che devi sapere.

Questo è piuttosto confuso come uno sviluppatore che scrive codice che interagisce con il servizio. Avrebbe molto più senso per me se il servizio rappresentasse un'eccezione che mi direbbe che l'utente non aveva le autorizzazioni appropriate per caricare questa cosa o crearla; Vorrei quindi immediatamente sapere perché il mio servizio non funzionava come previsto.

Lo sviluppatore più esperto che ha scritto il servizio ha sostenuto che la richiesta dei dati non è una condizione di errore e che le eccezioni dovrebbero essere lanciate solo in una condizione di errore, non quando l'utente non ha accesso ai dati. Questi dati vengono spesso cercati in una GUI e per quegli utenti senza le giuste autorizzazioni, queste cose semplicemente "non esistono". Quindi, in breve: chiedere non è sbagliato, quindi non fa eccezione. I metodi get restituiscono null perché a quegli utenti queste cose "non esistono". I metodi di creazione restituiscono null quando l'utente non è stato autorizzato a creare quella cosa.

È normale e / o buona pratica? Preferisco usare le eccezioni perché trovo molto più facile sapere cosa sta succedendo. Quindi, ad esempio, preferirei anche lanciare NotFoundException se chiedessi un oggetto con un ID non valido, piuttosto che restituire null.

Le eccezioni dovrebbero essere lanciate solo quando c'è un errore e chiedere una cosa non è un errore.

Chiedere una cosa potrebbe non essere un errore, ma non avere i permessi per qualcosa che hai chiesto è sicuramente una sorta di errore. Le eccezioni sono un modo alternativo per segnalare condizioni eccezionali, da utilizzare al posto di valori di ritorno speciali (come null, come , come hai scritto, non è assolutamente di aiuto se ci sono> 1 possibili ragioni per cui le cose potrebbero andare male (anche se ci sono esattamente 1 possibile motivo ora, potrebbero esserci 2 possibili motivi nella prossima versione, quindi l'utilizzo nullcome valore di ritorno che indica che il fallimento si sarebbe dipinto in un angolo)). Se il servizio non segnala in alcun modo perché non farà ciò che hai richiesto, allora è sicuramente un cattivo design.

Se utilizzare un valore di ritorno speciale (ad esempio numeri interi negativi sono utili per le funzioni che normalmente restituiscono un numero intero non negativo), un'eccezione, un gestore di errori globale o un logger ecc., È un dettaglio di implementazione alla fine. La scelta dipende dalla lingua, dalla situazione, dalle convenzioni ed è anche una questione di gusti. Il punto principale è che dovrebbe esserci un modo diretto per scoprire perché qualcosa non funziona. Altrimenti la tua unica opzione è quella di andare in giro con diverse opzioni e qualunque cosa per scoprire cosa è correlato al comportamento della scatola nera, ed è una perdita di tempo.

String.substring()genera un IndexOutOfBoundsExceptionse l'indice è fuori limite. Non riesco a pensare a nessun vantaggio al ritorno null, anche se - filosoficamente - si potrebbe sostenere che a Stringnon contenga nulla al di fuori dei suoi limiti, quindi allora nullsarebbe un valore di ritorno logico. Essere logico-filosofici ed essere pratici sono ovviamente due diversi animali.

Dipende dal contratto. Se il tuo contratto dice che puoi richiedere qualcosa che non esiste, dovrebbe dire cosa succede (oggetto null o null).

D'altra parte, se il tuo contratto dice che dovresti prima chiamare un metodo diverso ( DoesSomethingExist()) e quindi chiamare il Getmetodo, allora il tuo contratto potrebbe dire che puoi ottenere solo cose che esistono e generare un'eccezione se non lo fanno. Il messaggio di eccezione potrebbe dire qualcosa del tipo "Assicurati di chiamare DoesSomethingExist()prima" che è un utile messaggio di errore.

Non esiste una risposta unica per tutti alla domanda. Se utilizzare le eccezioni o restituire null dipende dalla situazione.

Invece di guardare questo puramente da un punto di vista dogmatico, guarda l'interfaccia come un'interfaccia utente . Le interfacce utente dovrebbero essere utilizzabili . Quindi, indipendentemente dalle tue opinioni sul modo "giusto" di fare qualcosa, scegli il metodo più utilizzabile dal punto di vista di qualcuno che usa la tua interfaccia.

Se il chiamante deve sapere perché un oggetto non viene restituito, un'eccezione è appropriata. Se, tuttavia, il concetto generale è "se non si dispone dell'autorizzazione, non esiste", il valore nullo è accettabile.

In particolare nel tuo caso, direi che i null sono perfettamente accettabili per la ricerca di un elemento se al chiamante viene richiesto per la prima volta di accedere o connettersi al server. Questo è quando ti verrà detto che hai o non hai il permesso. Una volta superato il cancello è ragionevole che quando cerchi qualcosa che non hai il permesso di vedere (o addirittura sai che esiste), dovresti ottenere un valore nullo.

Se, d'altra parte, non si dispone di una connessione iniziale o di una fase di accesso, un'eccezione ha senso. Se il chiamante sa che esiste un elemento e non lo sta recuperando, l'API non è utile per restituire un valore nullo.

Per creare un oggetto, tuttavia, questa è una storia diversa. Presumibilmente potrebbero esserci molte ragioni per fallire: nessuna autorizzazione, parametri errati, memoria insufficiente del server, ecc. Se allo sviluppatore viene assegnato un valore nullo per tutte queste condizioni, non ha modo di determinare un corretto corso d'azione .

Quindi, per rispondere alla domanda, chiediti qual è la soluzione più utilizzabile dal punto di vista di qualcuno che utilizza il servizio. Può darsi che il modo in cui lo usi sia atipico, e per il caso più comune un null è la risposta giusta.

Quindi, non entrare in una guerra religiosa per questo, decidi cosa è giusto per questo particolare problema.

Sicuramente penso che sia un cattivo design . Null-pointer non è una risposta valida per me e può essere difficile da gestire.

Se l'utente prova a connettere un servizio senza le credenziali appropriate, dovrei rispondere con una risposta chiara e concisa. La risposta potrebbe essere un'eccezione o un oggetto speciale ma non nulla.

È necessario lasciare la risposta nulla in caso di interruzione del collegamento di rete o di altri malfunzionamenti critici imprevisti.

Inoltre, il tempo impiegato a capire perché hai ottenuto un valore nullo è un argomento forte. Qualsiasi parte di codice dovrebbe essere facile da capire e da usare. Avere un valore nullo non è il caso.

Tenendo presente una buona progettazione del software, dovresti pensare alla vita del tuo progetto.
Restituendo null, come è stato detto, non si fornisce alcuna informazione al cliente. Guarda cosa ti è successo, all'inizio non ti sei reso conto di dove fosse il problema. Inoltre, se non viene fornita alcuna documentazione, questo è un casino.

Lanciando un'eccezione, puoi dire cosa è andato storto. Puoi anche personalizzare il testo visualizzato per essere più specifico se lo desideri.

D'altra parte, ritornando nullfai indurre il cliente a indagare su ciò che sta succedendo.

Inoltre, ti sei reso conto che c'era un problema perché sei arrivato altrove a NullPointerException. Ora immagina di non memorizzare il ritorno di quella funzione ... Sarai costretto a circondare ogni chiamata a quella funzione con un if elseblocco ...

Dal mio punto di vista, il ritorno nullè una cattiva pratica.

Lo sviluppatore più esperto che ha scritto il servizio ha sostenuto che la richiesta dei dati non è una condizione di errore e che le eccezioni dovrebbero essere lanciate solo in una condizione di errore, non quando l'utente non ha accesso ai dati.

Dal mio punto di vista, questo non ha senso.

La richiesta di dati senza autorizzazione dovrebbe comportare un'eccezione, poiché si tratta di un risultato imprevisto , per non ottenere alcun risultato, senza un accesso adeguato.

Analogia : il codice di risposta per una GETsenza autorizzazione non è 200 okprivo di dati, in realtà è 401 Unauthorized.

Restituire null non è eccezionale. Non ti dice niente. Per fare un esempio, se un'app sta cercando di cercare qualcosa e la risposta è nulla per entrambi i problemi di sicurezza e se l'elemento non esiste, come si fa a distinguere tra i due?

Una risposta significativa può consentire all'applicazione di effettuare scelte logiche su cosa fare in seguito o su come risolvere i problemi.

Se la causa principale è un utente non autenticato, preferisco una risposta HTTP 401 rigida, forse con un reindirizzamento a una pagina di messaggi piuttosto (e una notifica a qualcuno che se ne frega). Le cause relative all'autorizzazione sono più caso per caso; ci sono argomenti per la restituzione di errori HTTP (403, diciamo) e argomenti per la restituzione di codici / messaggi speciali ben formati nella risposta del servizio.

Le eccezioni dovrebbero essere utilizzate solo in circostanze eccezionali e significa che qualcosa è andato storto. Non sono d'accordo sul fatto che dovrebbero essere sovraccarichi per significare "non consentito". (Lo stesso vale per il valore di ritorno null: non sono d'accordo sul fatto che dovrebbe essere usato per significare "non consentito".)

Per interpretare l'avvocato dei diavoli cercherò di prendere la parte del ritorno null.

Secondo me esiste solo una situazione in cui questo tipo di risposta è quasi accettabile e cioè, come in questo caso, quando si tratta di sicurezza.

È molto facile fornire accidentalmente dettagli del sistema che le persone non autorizzate non dovrebbero conoscere. Questo dovrebbe essere evitato.

Prendi, ad esempio, un controllo nome utente e password. Restituire un errore "Nome utente non trovato" e un errore "Password errata" come codici di errore separati ti aprirebbero ovviamente a gravi problemi di sicurezza in quanto qualcuno potrebbe prima cercare un nome utente valido e quindi cercare una password. Restituire un "Nome utente / password non validi" generici sarebbe un'opzione migliore.

Pertanto, in questo caso particolare direi che è quasi ok tornare, nullma sono d'accordo, sarebbe molto spiacevole lavorare con.

Penso che return null sia ostile, quando il client invoca questo metodo e restituisce null, il client non sa cosa è successo e perché ha restituito null. Quindi dovremmo lanciare l'esecuzione che ha senso e fornire una documentazione per descriverla.