IMHO se ciò è ok dipende principalmente dal contesto del metodo Do e da ciò che sai riguardo al materiale in try -block. Supponiamo che tu abbia un'applicazione di interfaccia utente e che la parte di Do sia solo un gestore Button-Click. Supponiamo ulteriormente che la parte all'interno del blocco try compia alcune cose non-UI abbastanza complesse che potrebbero fallire con qualsiasi tipo di eccezione non sostenibile (ma normalmente non dovrebbe, e quando succede, c'è stato qualcosa di grave). Quindi, se la tua strategia di gestione degli errori è quella di visualizzare il messaggio di eccezione all'utente e lasciargli decidere cosa fare dopo (ad esempio, può decidere di chiudere e riavviare l'applicazione, o di ignorare l'errore), quindi prendere tutto il tipo di eccezioni è solo la strada da percorrere. Potrebbe non essere una soluzione perfetta, ma è pragmatica e funziona per molti casi reali.
Ovviamente, dovresti assicurarti che l'utente abbia abbastanza informazioni per prendere la decisione giusta. In genere, un messaggio generale come "un'eccezione si è verificata" non è abbastanza informazioni. Quindi pensa a cosa puoi presentare ai tuoi utenti e cosa no. Se temi che il tuo utente tipico non riesca a capire il messaggio di errore, mostragli il "messaggio generale", ma assicurati che il personale di supporto o l'amministratore possano ricevere il messaggio reale in seguito (magari da un file di registro, magari da una voce di menu separata ecc.) Se utilizzi qualcosa come un file di registro, anche la registrazione dello stack trace dell'eccezione può essere una buona idea, poiché ti aiuterà (lo sviluppatore) a trovare la causa principale in caso di un errore interno del programma.
Tuttavia, se sai che la parte all'interno del blocco try può a volte generare un'eccezione che rende impossibile il tuo programma di procedere (come OutOfMemoryException , o forse un'eccezione che indica che un grave errore interno del programma si è verificato, o qualcosa del genere), dovresti prenderlo individualmente, mostrare il motivo del fallimento all'utente e terminare automaticamente il programma in un secondo momento. Pensa a quale sia il comportamento più user-friendly. Ha senso lasciare che l'utente decida se il programma dovrebbe procedere, o c'è una possibilità se l'utente ignora l'errore, che perderà o distruggerà parti dei suoi dati ora? Se è il caso, meglio non lasciare decidere all'utente - meglio terminare il programma in modo controllato.
Il primo era solo un esempio - il succo è: pensate alle responsabilità per la gestione degli errori: ciò che è nel vostro caso la responsabilità dell'utente, qual è la responsabilità della parte UI (il gestore di pulsanti), e qual è la responsabilità della parte nel blocco try - quindi puoi decidere quali eccezioni catturare e quali informazioni visualizzare.