Come sviluppatore, si incontrano spesso tale eccezione: NullReferenceException con il messaggio di errore ben noto:Perché "il riferimento all'oggetto non è impostato su un'istanza di un oggetto" non è più descrittivo?
riferimento oggetto non impostato a un'istanza di un oggetto
Non è possibile per il. Framework NET per restituire qualcosa di un po 'più significativo?
qualcosa come:
oggetto di tipo X di nome Y non fissato ad un un'istanza di un oggetto
Un oggetto non ha un nome, quindi come può dirvi il nome? Il riferimento null può essere stato caricato da una variabile - o potrebbe essere stato restituito da un metodo, la proprietà ecc
Il JIT potrebbe probabilmente un'occhiata alle informazioni dello stack di capire cosa il tipo di riferimento dichiarato era , ma non sono sicuro di quanto spesso questo possa essere d'aiuto - e senza dubbio rallenterebbe le cose.
Non posso dire di averlo mai trovato un grosso problema quando si tratta di eseguire il debug, se ci sono molte cose che possono essere nulle su una singola riga, che di solito suggerisce che vale la pena dividerle Di Più.
Perché il suo il modo più generico di dire che.
Per me sembra solo una questione di preferenza. Se ti infastidisce così tanto, potresti sempre sottoclassi lo NullReferenceException e cambiare il messaggio. :)
Ciò che si riduce a è la quantità di informazioni disponibili quando viene creato il messaggio. Senza passare manualmente alcune informazioni aggiuntive, la semplice determinazione del nome del campo che era nullo all'interno di NullReferenceException richiederebbe una riflessione (probabilmente anche un po '), che è un'operazione piuttosto pesante. Prendiamo ad esempio lo ArgumentNullException, per lanciarne uno in cui il messaggio indica il nome del parametro offendente, devi passare una stringa quando lo chiami: throw new ArgumentNullException("param1").
Il livello di dettaglio in un messaggio di eccezione dipende interamente dal programmatore che lo definisce, ma è prudente evitare di fare qualcosa di intenso sul sistema quando si genera un'eccezione.
Sono abbastanza sicuro che il framework lanci la NullReferenceException. – ChaosPandion
Lo fa, ma si potrebbe sempre 'try {} catch (NullReferenceException e) {throw new CoolerNullReferenceException (e)}' o qualcosa del genere. –
Ah Ho appena notato la faccina nella tua risposta. :) – ChaosPandion
Grazie alla traccia di stack estremamente dettagliata, non penso che sia necessario essere più dettagliato. Inoltre dovrebbero davvero usare assert per evitare questo in primo luogo. – ChaosPandion
Qualsiasi tipo di debugging rallenta le cose. Mi chiedo, comunque, se rallenterebbe le cose * tanto * rispetto a quanto accelererebbe le cose non dovendo tornare indietro e scomporre tutti gli oggetti in linee separate, o impazzire con la finestra immediata per capire quale oggetto è nullo? –
Concordato che questo problema non è oneroso. L'una o due righe prima di quella in cui si è verificata l'eccezione di riferimento null ti dirà esattamente cosa non viene inizializzato. –