parameter - parametros opcionales c#

Marcar los parámetros como NO anulables en C#/. NET?

Question

¿Existe un atributo simple o contrato de datos que pueda asignar a un parámetro de función que impida que se pase null en C # /. NET? Idealmente, esto también se verificaría en tiempo de compilación para asegurarse de que el null literal no se esté utilizando en ningún lugar para ello y en tiempo de ejecución arroje ArgumentNullException .

Actualmente escribo algo como ...

if (null == arg)
  throw new ArgumentNullException("arg");

... por cada argumento que espero que no sea null .

En la misma nota, ¿hay un opuesto a Nullable<> por el cual fallaría lo siguiente?

NonNullable<string> s = null; // throw some kind of exception

Answer 1

No hay nada disponible en tiempo de compilación, desafortunadamente.

Tengo un poco de una solución hacky que publiqué recientemente en mi blog, que usa una nueva estructura y conversiones.

En .NET 4.0 con las cosas de Contratos de código , la vida será mucho mejor. Todavía sería muy agradable tener una sintaxis de lenguaje real y soporte en torno a la no anulabilidad, pero los contratos de código ayudarán mucho.

También tengo un método de extensión en MiscUtil llamado ThrowIfNull que lo hace un poco más simple.

Un último punto: cualquier razón para usar " if (null == arg) " en lugar de " if (arg == null) "? Encuentro este último más fácil de leer, y el problema que el primero resuelve en C no se aplica a C #.

Answer 2

Ok esta respuesta es un poco tarde, pero así es como lo estoy resolviendo:

public static string Default(this string x)
{
    return x ?? "";
}

Use este método de exension, entonces puede tratar la cadena nula y vacía como la misma cosa.

P.ej

if (model.Day.Default() == "")
{
    //.. Do something to handle no Day ..
}

No es ideal, lo sé, ya que tiene que recordar llamar al valor predeterminado en todas partes, pero es una solución.

Answer 3

Sé que esta es una pregunta MUY vieja, pero esta faltaba aquí:

Si usa ReSharper, puede usar el Marco Anotado .

Answer 4

Sé que soy muy tarde para esta pregunta, pero creo que la respuesta se volverá relevante a medida que la última versión principal de C # se acerque a su lanzamiento y luego se lance. En C # 8.0 se producirá un cambio importante, C # asumirá que todos los tipos se consideran no nulos.

De acuerdo con Mads Torgersen:

El problema es que las referencias nulas son muy útiles. En C #, son el valor predeterminado de cada tipo de referencia. ¿Qué más sería el valor predeterminado? ¿Qué otro valor tendría una variable, hasta que pueda decidir qué más asignarle? ¿Con qué otro valor podríamos alisar una serie de referencias recientemente asignadas, hasta que llegue el momento de completarlas?

Además, a veces nulo es un valor sensible en sí mismo. Algunas veces quiere representar el hecho de que, digamos, un campo no tiene un valor. Que está bien pasar "nada" por un parámetro. El énfasis está puesto a veces, sin embargo. Y aquí está otra parte del problema: los lenguajes como C # no le permiten expresar si un nulo aquí es una buena idea o no.

Entonces, la resolución descrita por Mads es:

1. Creemos que es más común querer una referencia que no sea nula. Los tipos de referencia anulables serían más raros (aunque no tenemos buenos datos para decirnos cuánto), por lo que son los que deberían requerir una nueva anotación.

2. El lenguaje ya tiene una noción de - y una sintaxis para - tipos de valores que aceptan nulos. La analogía entre los dos haría la adición del lenguaje conceptualmente más fácil y lingüísticamente más simple.

3. Parece correcto que no deba agobiarse ni a usted ni a su consumidor con valores nulos engorrosos a menos que haya decidido activamente que los quiere. Los nulos, no la ausencia de ellos, deberían ser aquello a lo que explícitamente debes optarte.

Un ejemplo de la característica deseada:

public class Person
{
     public string Name { get; set; } // Not Null
     public string? Address { get; set; } // May be Null
}

La vista previa está disponible para Visual Studio 2017, 15.5.4 o vista previa.

Answer 5

Verifique los validadores en la biblioteca de la empresa. Puedes hacer algo como:

private MyType _someVariable = TenantType.None;
[NotNullValidator(MessageTemplate = "Some Variable can not be empty")]
public MyType SomeVariable {
    get {
        return _someVariable;
    }
    set {
        _someVariable = value;
    }
}

Luego en tu código cuando quieras validarlo:

Microsoft.Practices.EnterpriseLibrary.Validation.Validator myValidator = ValidationFactory.CreateValidator<MyClass>();

ValidationResults vrInfo = InternalValidator.Validate(myObject);

Answer 6

no es el más lindo, pero:

public static bool ContainsNullParameters(object[] methodParams)
{
     return (from o in methodParams where o == null).Count() > 0;
}

también podría obtener más creatividad en el método ContainsNullParameters:

public static bool ContainsNullParameters(Dictionary<string, object> methodParams, out ArgumentNullException containsNullParameters)
       {
            var nullParams = from o in methodParams
                             where o.Value == null
                             select o;

            bool paramsNull = nullParams.Count() > 0;


            if (paramsNull)
            {
                StringBuilder sb = new StringBuilder();
                foreach (var param in nullParams)
                    sb.Append(param.Key + " is null. ");

                containsNullParameters = new ArgumentNullException(sb.ToString());
            }
            else
                containsNullParameters = null;

            return paramsNull;
        }

por supuesto, podría usar un interceptor o una reflexión, pero estos son fáciles de seguir / usar con poca sobrecarga

Answer 7

public void foo(int? id, string name)
{
    if (id == null)
    {
       throw new ArgumentNullException("id");
    }
    if (name == null)
    {
       throw new ArgumentNullException("name");
    }

    this.foo = id.Value;
    this.fooName = name;
}

Ahí va, de lo contrario solo defina otra declaración.