Devo lanciare un'eccezione in caso di un valore significativo al di fuori dell'intervallo o gestirlo da solo?

Ho scritto una struttura che rappresenta le coordinate di latitudine / longitudine. I loro valori vanno da -180 a 180 per le longitudini e da 90 a -90 per le latitudini.

Se un utente di quella struttura mi dà un valore al di fuori di tale intervallo, ho 2 opzioni:

1. Lancia un'eccezione (arg fuori portata)
2. Converti il ​​valore in vincolo

Poiché una coordinata di -185 ha un significato (può essere facilmente convertita in +175 in quanto sono coordinate polari), potrei accettarla e convertirla.

È meglio generare un'eccezione per dire all'utente che il suo codice mi ha dato un valore che non avrebbe dovuto avere?

Modifica: Conosco anche la differenza tra lat / lng e coordinate, ma volevo semplificarlo per una discussione più semplice - non era la più brillante delle idee

Se il nocciolo della tua domanda è questo ...

Se un codice client passa un argomento il cui valore non è valido per la cosa che la mia struttura dati sta modellando, dovrei rifiutare il valore o convertirlo in qualcosa di sensato?

... allora la mia risposta generale sarebbe "rifiutare", perché questo aiuterà ad attirare l'attenzione su potenziali bug nel codice client che stanno effettivamente facendo apparire il valore non valido nel programma e raggiungere il costruttore. Attirare l'attenzione sui bug è generalmente una proprietà desiderata nella maggior parte dei sistemi, almeno durante lo sviluppo (a meno che non sia una proprietà desiderata del sistema da confondere in caso di errori).

La domanda è se stai effettivamente affrontando quel caso .

• Se la tua struttura di dati ha lo scopo di modellare le coordinate polari in generale, accetta il valore perché gli angoli al di fuori dell'intervallo -180 e +180 non sono realmente validi. Sono perfettamente validi e capita sempre che abbiano sempre un equivalente compreso tra -180 e +180 (e se vuoi convertirli in tale intervallo, sentiti libero - il codice client di solito non ha bisogno di cura) .

• Se la tua struttura di dati sta modellando esplicitamente le coordinate di Web Mercator (secondo la domanda nella sua forma iniziale), allora è meglio seguire le disposizioni menzionate nelle specifiche (che non conosco, quindi non dirò nulla al riguardo) . Se la specifica della cosa che stai modellando dice che alcuni valori non sono validi, respingili. Se dice che possono essere interpretati come qualcosa di sensato (e quindi sono effettivamente validi), accettali.

Il meccanismo che usi per segnalare se i valori sono stati accettati o meno dipende dalle caratteristiche della tua lingua, dalla sua filosofia generale e dai tuoi requisiti di prestazione. Quindi, potresti lanciare un'eccezione (nel costruttore) o restituire una versione nullable della tua struttura (attraverso un metodo statico che invoca un costruttore privato) o restituire un valore booleano e passare la tua struttura al chiamante come outparametro (di nuovo tramite un metodo statico che richiama un costruttore privato) e così via.

Dipende molto. Ma dovresti decidere di fare qualcosa e documentarlo .

L'unica cosa assolutamente sbagliata da fare per il tuo codice è dimenticare di considerare che l'input dell'utente potrebbe essere al di fuori dell'intervallo previsto e scrivere il codice che ha un comportamento accidentale. Perché allora alcune persone faranno un'ipotesi errata su come si comporta il tuo codice e causerà bug, mentre altri finiranno a seconda del comportamento che il tuo codice ha accidentalmente (anche se quel comportamento è completamente disordinato) e quindi causerai più bug quando in seguito risolverai il problema.

In questo caso posso vedere gli argomenti in entrambi i modi. Se qualcuno viaggia +10 gradi da 175 gradi, dovrebbe finire a -175. Se normalizzi sempre l'input dell'utente e tratti 185 come equivalente a -175, il codice client non può fare la cosa sbagliata quando aggiunge 10 gradi; ha sempre l'effetto giusto. Se trattate 185 come un errore, forzate ogni caso in cui il codice client sta aggiungendo gradi relativi da inserire nella logica di normalizzazione (o almeno ricordate di chiamare la vostra procedura di normalizzazione), in realtà causeretebug (anche se si spera sia facile catturare quelli che verranno rapidamente schiacciati). Ma se un numero di longitudine viene inserito dall'utente, scritto letteralmente nel programma o calcolato attraverso una procedura intesa sempre in [-180, 180), è molto probabile che un valore al di fuori di tale intervallo indichi un errore, quindi "utile "convertirlo potrebbe nascondere problemi.

Il mio ideale in questo caso sarebbe probabilmente quello di definire un tipo che rappresenti il ​​dominio corretto. Usa un tipo astratto (non lasciare che il codice client acceda semplicemente ai numeri non elaborati al suo interno) e fornisci sia una fabbrica normalizzante che una validatrice (in modo che il client possa effettuare il compromesso). Ma qualunque sia il valore di questo tipo, 185 dovrebbe essere indistinguibile da -175 quando visto attraverso l'API pubblica (non importa se sono convertiti in costruzione o se si forniscono uguaglianza, accessori e altre operazioni che ignorano in qualche modo la differenza) .

Se non ti interessa davvero scegliere una soluzione, puoi semplicemente lasciare decidere all'utente.

Dato che la tua struttura è di sola lettura e creata da un metodo / costruttore, potresti fornire due sovraccarichi in base alle opzioni che l'utente ha:

• Lancia un'eccezione (arg fuori portata)
• Converti il ​​valore in vincolo

Inoltre, non lasciare che l'utente abbia una struttura non valida per passare ad altri metodi, rendilo giusto alla creazione.

Modifica: in base ai commenti, suppongo che tu stia utilizzando c #.

Dipende se l'input proviene direttamente da un utente tramite un'interfaccia utente o dal sistema.

Input attraverso un'interfaccia utente

È una domanda sull'esperienza utente come gestire input non validi. Non conosco il tuo caso specifico, ma in generale ci sono alcune opzioni:

• Avvisare l'utente dell'errore e chiedere all'utente di risolverlo prima di procedere (Più comune)
• Converti automaticamente nell'intervallo valido (se possibile), ma avvisa l'utente della modifica e consenti all'utente di verificare prima di procedere.
• Converti silenziosamente nell'intervallo valido e procedi.

La scelta dipende dalle aspettative dei tuoi utenti e dalla criticità dei dati. Ad esempio, Google corregge automaticamente l'ortografia nelle query, ma questo è a basso rischio perché una modifica non utile non è un problema ed è facile da risolvere (e anche in questo caso nella pagina dei risultati viene chiarito che la query è stata modificata). D'altra parte, se si stanno inserendo le coordinate per un missile nucleare, si potrebbe desiderare una convalida dell'input più rigida e nessuna correzione silenziosa di dati non validi. Quindi non esiste una risposta universale.

Ancora più importante, dovresti considerare se la correzione dell'input ha anche un vantaggio per l'utente. Perché un utente dovrebbe inserire dati non validi? È facile vedere come qualcuno potrebbe commettere un errore di ortografia, ma perché qualcuno dovrebbe inserire una longitudine di -185? Se l'utente intendesse davvero +175 probabilmente avrebbero digitato +175. Penso che sia molto probabile che una longitudine non valida sia semplicemente un errore di battitura, e l'utente intendesse -85 o qualcos'altro. In questo caso la conversione silenziosa è dannosa e inutile . L'approccio più intuitivo per la tua app sarebbe probabilmente quello di avvisare l'utente del valore non valido e farlo correggere da solo.

Input tramite un'API

Se l'input proviene da un altro sistema o sottosistema, non c'è dubbio. Dovresti lanciare un'eccezione. Non si dovrebbe mai silenzioso convertire input non validi da un altro sistema, poiché potrebbe mascherare errori altrove nel sistema. Se l'input viene "corretto", dovrebbe avvenire nel livello dell'interfaccia utente, non più in profondità nel sistema.

Dovresti lanciare un'eccezione.

Nell'esempio che hai fornito, inviando 185 e convertendolo in -175, in alcuni casi potrebbe essere utile fornire tale funzionalità. E se il chiamante invia 1 milione? Intendono davvero convertirlo? Sembra più probabile che sia un errore. Quindi, se devi lanciare un'eccezione per 1.000.000 ma non per 185, devi prendere una decisione su una soglia arbitraria per lanciare un'eccezione. Tale soglia ti farà inciampare qualche volta mentre alcune app chiamanti inviano valori intorno alla soglia.

Meglio gettare l'eccezione per i valori fuori dall'intervallo.

L'opzione più conveniente per uno sviluppatore sarebbe un supporto per errori di compilazione nella piattaforma, per valori fuori range. In questo caso, anche l'intervallo dovrebbe far parte della firma del metodo, proprio come il tipo di parametri. Allo stesso modo in cui l'utente API non può passare una stringa se la firma del metodo è definita per assumere un numero intero , l'utente non avrebbe dovuto essere in grado di passare un valore senza verificare se il valore rientra nell'intervallo indicato nella firma del metodo. Se non selezionato, dovrebbe ricevere un errore di tempo di compilazione e, quindi, l'errore di runtime potrebbe essere evitato.

Ma attualmente, pochissimi compilatori / piattaforme supportano questo tipo di controllo del tempo di compilazione. Quindi, è un mal di testa per gli sviluppatori. Ma idealmente, il tuo metodo dovrebbe semplicemente generare un'eccezione significativa per i valori non supportati e documentarlo chiaramente.

A proposito, adoro il modello di errore proposto da Joe Duffy qui .

L'impostazione predefinita dovrebbe essere lanciare un'eccezione. Potresti anche consentire un'opzione simile strict=falsee fare la coercizione in base alla bandiera, dove ovviamente strict=trueè l'impostazione predefinita. Questo è abbastanza comune:

• Java DateFormatsupporta lenient .
• Il parser JSON di Gson supporta anche una modalità clemente .
• Eccetera.

Per me la migliore pratica è di non cambiare mai l'input dell'utente. L'approccio che di solito seguo è quello di separare la validazione dall'esecuzione.

• Avere una classe semplice che utilizza solo i parametri indicati.
• Utilizzare un decoratore per fornire un livello di convalida che può essere modificato a piacimento senza influire sulla classe di esecuzione (oppure iniettare un validatore se questo approccio è troppo difficile).