usa & try/catch nidificazione

Question

Questa domanda è più di una qual è il modo giusto per fare qualcosa ...

La domanda ... c'è un adeguato ordine di nidificazione tra un blocco using e try/catch?

È possibile nidificare l'intera istruzione using all'interno di un try/catch e mantenere i vantaggi di un blocco using? (o un'eccezione farà sì che la parte finale dell'istruzione using venga espulsa dalla finestra)

Oppure dovresti annidare lo try/catch all'interno delle dichiarazioni using e circondare solo le istruzioni che consentono l'accesso al database?

Is ...

try { 
    using(tsmtcowebEntities db = new tsmtcowebEntities()) { 
      violationList = (from a in db.DriverTrafficViolationDetails 
          where a.DriverTrafficViolation.DriverApplicationId == DriverAppId 
          orderby a.DateOfOccurance descending 
          select a).ToList<DriverTrafficViolationDetail>(); 
      GeneralViolation = (from a in db.DriverTrafficViolations 
           where a.DriverApplicationId == DriverAppId 
           select a).FirstOrDefault(); 
    } 
} catch { } 

meno/più corretto di ...

using(tsmtcowebEntities db = new tsmtcowebEntities()) { 
    try { 
      violationList = (from a in db.DriverTrafficViolationDetails 
          where a.DriverTrafficViolation.DriverApplicationId == DriverAppId 
          orderby a.DateOfOccurance descending 
          select a).ToList<DriverTrafficViolationDetail>(); 
      GeneralViolation = (from a in db.DriverTrafficViolations 
           where a.DriverApplicationId == DriverAppId 
           select a).FirstOrDefault(); 
    } catch { } 
} 

Answer 1

Il successivo è migliore: eviterà eccezioni di mascheratura eventualmente lanciate dy dispose. Vedere questo article.

Answer 2

Vorrei suggerire mettendo il try/catch all'interno del usando perché a prescindere dal fatto che un'eccezione è buttare si dovrebbe smaltire i tipi il contenitore dell'entità Disposable

Answer 3

È davvero una questione di stile e quanto ristretta si vuole mantenere l'ambito di db:

Se l'utilizzo è all'interno del blocco try/catch, la variabile db sarà accessibile solo nella porzione try.

Se l'utilizzo è esterno al blocco try/catch, sarà visibile all'interno della parte catch.

Indipendentemente da ciò, la variabile verrà eliminata correttamente perché il blocco using equivale a try/finally.

Personalmente mi chiederei perché è necessario rilevare eccezioni in assoluto e cosa, se non altro, si è in grado di fare con loro.

Answer 4

using nidi prevedibilmente con try/catch e Dispose saranno chiamati tutti su sentieri. Si intende che il controllo è sempre flussi da interni -> ambiti esterni (sia per Eccezioni che per il ritorno normale del flusso).

La domanda è allora: quando qualora il cattura essere eseguito in relazione al Dispose e cosa qualora il campo di applicazione della cattura essere? La risposta a questo può variare a seconda del codice ma deve essere ovviamente "all'interno" se è richiesto l'accesso a db e "all'esterno" se il codice è eseguito comeusing * potrebbe essere l'origine dell'eccezione.

(Inoltre, blocchi catch vuoti sono icky! Io parto dal presupposto che ci sono "a scopo dimostrativo".)

Felice di codifica.

---

* Si noti che un esterno catture interferirà eccezioni generate da new tsmtcowebEntities() o (come sottolineato da J.N.) il Dispose, dovrebbe qualsiasi esistere. (È un altro argomento interamente se è accettabile che entrambi i costrutti generino un'eccezione ;-) Preferisco catturare le eccezioni il più vicino possibile alla sorgente e lasciare che le eccezioni non sappiano come gestire "bleed out" escluso in determinati costrutti di livello superiore (ad es. Gestori di eventi).