Migliore eccezione per un argomento di tipo generico non valido

Attualmente sto scrivendo del codice per UnconstrainedMelody che ha metodi generici a che fare con le enumerazioni.

Ora, ho una classe statica con un sacco di metodi che sono solo pensato per essere utilizzato con le enumerazioni "bandiere". Non posso aggiungerlo come vincolo ... quindi è possibile che vengano chiamati anche con altri tipi di enum. In tal caso, vorrei lanciare un'eccezione, ma non sono sicuro di quale lanciare.

Giusto per renderlo concreto, se ho qualcosa del genere:

// Returns a value with all bits set by any values
public static T GetBitMask<T>() where T : struct, IEnumConstraint
{
    if (!IsFlags<T>()) // This method doesn't throw
    {
        throw new ???
    }
    // Normal work here
}

Qual è la migliore eccezione da lanciare? ArgumentExceptionsembra logico, ma è un argomento di tipo piuttosto che un normale argomento, che potrebbe facilmente confondere le cose. Devo presentare la mia TypeArgumentExceptionclasse? Utilizzare InvalidOperationException? NotSupportedException? Qualunque altra cosa?

Vorrei piuttosto non creare il mio eccezione per questo meno che non sia chiaramente la cosa giusta da fare.

NotSupportedException sembra che si adatti perfettamente, ma la documentazione afferma chiaramente che dovrebbe essere usato per uno scopo diverso. Dalle osservazioni della classe MSDN:

Esistono metodi che non sono supportati nella classe base, con l'aspettativa che questi metodi vengano invece implementati nelle classi derivate. La classe derivata potrebbe implementare solo un sottoinsieme dei metodi dalla classe base e generare NotSupportedException per i metodi non supportati.

Naturalmente, c'è un modo in cui NotSupportedExceptionè ovviamente abbastanza buono, soprattutto dato il suo significato di buon senso. Detto questo, non sono sicuro che sia giusto.

Dato lo scopo di Unconstrained Melody ...

Ci sono varie cose utili che possono essere fatte con metodi / classi generici in cui c'è un vincolo di tipo "T: enum" o "T: delegate" - ma sfortunatamente, quelli sono proibiti in C #.

Questa libreria di utilità aggira i divieti usando ildasm / ilasm ...

... sembra che un nuovo Exceptionpotrebbe essere in ordine nonostante l'elevato onere della prova che dobbiamo giustamente soddisfare prima di creare un costume Exceptions. Qualcosa di simile InvalidTypeParameterExceptionpotrebbe essere utile in tutta la libreria (o forse no - questo è sicuramente un caso limite, giusto?).

I clienti dovranno essere in grado di distinguerlo dalle eccezioni BCL? Quando un cliente potrebbe chiamarlo accidentalmente usando una vaniglia enum? Come rispondereste alle domande poste dalla risposta accettata a Quali fattori dovrebbero essere presi in considerazione quando si scrive una classe di eccezione personalizzata?

Eviterei NotSupportedException. Questa eccezione viene utilizzata nel framework in cui un metodo non è implementato ed è presente una proprietà che indica che questo tipo di operazione non è supportato. Non sta qui

• Self Reference senza vergogna: http://blogs.msdn.com/jaredpar/archive/2008/12/12/notimplementedexception-vs-notsupportedexception.aspx

Penso che InvalidOperationException sia l'eccezione più appropriata che potresti lanciare qui.

La programmazione generica non dovrebbe generare in fase di esecuzione per parametri di tipo non valido. Non dovrebbe essere compilato, dovresti avere un'applicazione in fase di compilazione. Non so cosa IsFlag<T>()contenga, ma forse puoi trasformarlo in un'applicazione in fase di compilazione, come provare a creare un tipo che è possibile creare solo con i "flag". Forse una traitsclasse può aiutare.

Aggiornare

Se devi lanciare, voterei per InvalidOperationException. Il ragionamento è che i tipi generici hanno parametri e gli errori relativi ai parametri (metodo) sono incentrati sulla gerarchia ArgumentException. Tuttavia, la raccomandazione su ArgumentException lo afferma

se l'errore non coinvolge gli argomenti stessi, è necessario utilizzare InvalidOperationException.

C'è almeno un atto di fede in questo, che le raccomandazioni sui parametri del metodo devono essere applicate anche a parametri generici , ma non c'è niente di meglio nella gerarchia SystemException imho.

Vorrei usare NotSupportedException poiché è quello che stai dicendo. Enumerazioni diverse da quelle specifiche non sono supportate . Ciò sarebbe ovviamente affermato più chiaramente nel messaggio di eccezione.

Andrei con NotSupportedException. Anche se ArgumentExceptionsembra a posto, è davvero previsto quando un argomento passato a un metodo è inaccettabile. Un argomento di tipo è una caratteristica che definisce il metodo effettivo che si desidera chiamare, non un vero "argomento". InvalidOperationExceptiondovrebbe essere lanciato quando l'operazione che stai eseguendo può essere valida in alcuni casi ma per la situazione particolare, è inaccettabile.

NotSupportedExceptionviene generato quando un'operazione è intrinsecamente non supportata. Ad esempio, quando si implementa un'interfaccia in cui un particolare membro non ha senso per una classe. Questa sembra una situazione simile.

Apparentemente, Microsoft usa ArgumentExceptionper quello, come dimostrato nell'esempio di Expression.Lambda <> , Enum.TryParse <> o Marshal.GetDelegateForFunctionPointer <> nella sezione Eccezioni. Non sono riuscito a trovare alcun esempio che indichi diversamente (nonostante la ricerca di una fonte di riferimento locale per TDelegatee TEnum).

Quindi, penso che sia lecito ritenere che almeno nel codice Microsoft sia una pratica comune da utilizzare ArgumentExceptionper argomenti di tipo generico non validi oltre a quelli variabili di base. Dato che la descrizione dell'eccezione nei documenti non discrimina tra quelle, non è nemmeno troppo eccessiva.

Si spera che decida una volta per tutte la questione.

Id andare con NotSupportedExpcetion.

Lanciare un'eccezione su misura dovrebbe sempre essere fatto in ogni caso in cui sia discutibile. Un'eccezione personalizzata funzionerà sempre, indipendentemente dalle esigenze degli utenti API. Lo sviluppatore potrebbe rilevare entrambi i tipi di eccezione se non gli interessa, ma se lo sviluppatore necessita di una gestione speciale sarà SOL.

Che ne dici di ereditare da NotSupportedException. Anche se sono d'accordo con @Mehrdad sul fatto che abbia più senso, ho sentito il tuo punto di vista sul fatto che non sembra adattarsi perfettamente. Quindi eredita da NotSupportedException e in questo modo le persone che codificano in base alla tua API possono comunque rilevare un'eccezione NotSupportedException.

Sono sempre diffidente nel scrivere eccezioni personalizzate, semplicemente per il fatto che non sono sempre documentate chiaramente e creano confusione se non vengono nominate correttamente.

In questo caso, avrei lanciato un'eccezione ArgumentException per il fallimento del controllo dei flag. Dipende tutto dalle preferenze. Alcuni standard di codifica che ho visto arrivano al punto di definire quali tipi di eccezioni dovrebbero essere lanciati in scenari come questo.

Se l'utente stava tentando di passare qualcosa che non era un'enumerazione, avrei lanciato un'eccezione InvalidOperationException.

Modificare:

Gli altri sollevano un punto interessante che questo non è supportato. La mia unica preoccupazione con una NotSupportedException è che generalmente quelle sono le eccezioni che vengono lanciate quando la "materia oscura" è stata introdotta nel sistema, o per dirla in un altro modo, "Questo metodo deve entrare nel sistema su questa interfaccia, ma abbiamo vinto non attivarlo fino alla versione 2.4 "

Ho anche visto NotSupportedExceptions lanciare un'eccezione di licenza "stai eseguendo la versione gratuita di questo software, questa funzione non è supportata".

Modifica 2:

Un altro possibile:

System.ComponentModel.InvalidEnumArgumentException  

Eccezione generata quando si utilizzano argomenti non validi che sono enumeratori.

Voterei anche per InvalidOperationException. Ho fatto un diagramma di flusso (incompleto) sulle linee guida di lancio di eccezioni .NET basate sulle linee guida di progettazione del framework 2nd Ed. un po 'di tempo fa se qualcuno è interessato.