Come forzare l'utilizzo del tentativo/catturare metodi specifici

Question

Sto creando una libreria "comune" da utilizzare come riferimento in vari progetti di soluzione da altri membri del team. I metodi sono in genere void funzioni senza dati restituiti effettivi.

Sto cercando un perché forzare l'uso di questi metodi all'interno di a Try...Catch blocco da altri. Devo assicurarmi che gli errori siano gestiti correttamente. Ho pensato di fare affidamento su un tipo di ritorno booleano, ma questo non mi permetterà di restituire anche il messaggio di errore, quindi la mia unica opzione è lanciare un Exception.

Se non è possibile una corretta forzatura, come posso creare un attributo che viene visualizzato quando si compila per avvertire lo sviluppatore del requisito di prova/cattura? (una specie di Obsolete attributo).

Altri approcci migliori?

MODIFICARE:

Ecco il mio scenario completo:

Ho un metodo di codice che chiama un servizio Web per aggiornare un valore in remoto. L'aggiornamento è abbastanza cruciale. Il metodo si auto funziona bene, ma cosa succede se il servizio web non è raggiungibile? La chiamata non restituisce alcun valore.

Answer 1

Posizionando qualcosa all'interno di a try/catch il blocco non lo rende "gestito correttamente" - in effetti, nel stragrande maggioranza Dei casi, il modo corretto di gestire un'eccezione è di lasciarlo bolle al livello successivo. Avvertimento: try/finally è molto più comune, consentire la pulizia delle risorse, ma ancora più comune di quello using.

Non puoi applicare "e devi usarlo correttamente" sul codice; Ciò è implicito in qualsiasi API e causerai solo irritazione e fastidio e costringendo le persone a stili di codifica inappropriati e inutili completamente artificiale e errato senso del codice corretto.

Se vuoi essere sicuro che il codice funzioni correttamente: testalo.

Non ci sono attributi che puoi usare per questo scenario. Probabilmente puoi creare una regola FXCOP o simile, ma per i motivi sopra: non la consiglio.

Answer 2

In realtà non lo farei, ma come soluzione divertente al problema dichiarato potresti costruire il tuo tipo di eccezione: una Exception di successo. Quindi, lanci questa eccezione alla fine del metodo per indicare il successo. Questo rende il metodo praticamente inutilizzabile senza qualche forma di prova/cattura. Ma, ancora: Non farlo.

Answer 3

Potresti restituire una classe di risultati personalizzati:

public class Result
{
    public bool Okay { get; set; }
    public string Error { get; set; }
}

Quindi:

var result = AttemptSomething();

if (!result.Okay)
{
    Console.WriteLine(result.Error);
}

---

O forse ritorna string:

var error = AttemptSomething();

if (!String.IsNullOrEmpty(error))
{
    Console.WriteLine(error);
}

---

O avere l'errore come out:

string error;
if (!AttemptSomething(out error))
{
    Console.WriteLine(error);
}

---

O ritorno Exception ma non gettare.