Ho letto molti articoli (e un paio di altre domande simili che sono state pubblicate su StackOverflow) su come e quando utilizzare le asserzioni e le ho comprese bene. Ma ancora, non capisco quale tipo di motivazione dovrebbe spingermi a usare Debug.Assert
invece di lanciare una semplice eccezione. Quello che voglio dire è che in .NET la risposta predefinita a un'asserzione fallita è "fermare il mondo" e visualizzare una finestra di messaggio per l'utente. Sebbene questo tipo di comportamento possa essere modificato, trovo che sia estremamente fastidioso e ridondante farlo, mentre potrei invece semplicemente lanciare un'eccezione adeguata. In questo modo, potrei facilmente scrivere l'errore nel registro dell'applicazione appena prima di lanciare l'eccezione e, inoltre, la mia applicazione non si blocca necessariamente.
Quindi, perché dovrei, se non del tutto, usare Debug.Assert
invece di una semplice eccezione? Posizionare un'asserzione dove non dovrebbe essere potrebbe causare tutti i tipi di "comportamento indesiderato", quindi dal mio punto di vista, non guadagno davvero nulla usando un'asserzione invece di lanciare un'eccezione. Sei d'accordo con me o mi sto perdendo qualcosa qui?
Nota: capisco perfettamente qual è la differenza "in teoria" (Debug vs Release, modelli di utilizzo ecc.), Ma per come la vedo io, farei meglio a lanciare un'eccezione invece di eseguire un'asserzione. Dal momento che se viene scoperto un bug in una versione di produzione, vorrei comunque che l '"asserzione" fallisse (dopotutto, l' "overhead" è ridicolmente piccolo), quindi sarebbe meglio lanciare un'eccezione invece.
Modifica: per come la vedo io, se un'asserzione non è riuscita, significa che l'applicazione è entrata in una sorta di stato corrotto e imprevisto. Allora perché dovrei voler continuare l'esecuzione? Non importa se l'applicazione viene eseguita su una versione di debug o di rilascio. Lo stesso vale per entrambi