¿Por qué el delegado no maneja el evento nulo?

Question

Al llamar a un delegado, siempre debe verificar si no es nulo. Esto es a menudo causa de errores. Dado que los delegados son más o menos solo una lista de funciones, supongo que esto podría haber sido fácilmente verificado por el delegado.

¿Alguien sabe por qué se ha implementado tal cual?

Answer 1

Supongo que las razones son la historia y la coherencia.

Es consistente con la forma en que se manejan otros tipos; p.ej.no hay asistencia de idioma o plataforma al tratar con null s - es responsabilidad de los programadores asegurarse de que el marcador de posición nulo nunca se use realmente - no hay forma de llamar solo opcionalmente a un método si la referencia de objeto que desea invocar tampoco es nula , después de todo.

Es historia, ya que las referencias nulas se incluyen por defecto en la mayoría de los tipos, aunque esto no es necesario. Es decir, en lugar de tratar los tipos de referencia como los tipos de valor y requieren una anotación adicional de "anulabilidad" para permitir la anulación, los tipos de referencia son siempre nullable. Estoy seguro de que hubo razones para esto en el pasado cuando se diseñaron Java y .NET, pero presenta muchos errores innecesarios y complejidades que son fáciles de evitar en un lenguaje fuertemente tipado (por ejemplo, tipos de valores .NET). Pero dada la inclusión histórica de null como un valor "inválido" de todo el sistema de tipos, por así decirlo, es natural que lo haga también para los delegados.

Answer 2

Si una instancia de delegado es null, ¿cómo puede "verificarse a sí mismo"? Es null ... eso significa que no existe, básicamente. No hay nada allí para controlarse en primer lugar. Es por eso que su código que intenta llamar al delegado debe hacer esa comprobación, primero.

Answer 3

El delegado no puede verificarlo. Como es nulo, no puede invocar métodos en él.

El compilador C# por otro lado podría insertar automáticamente la verificación nula. Pero no sé qué comportamiento usar si el delegado es una función con un valor de retorno.

Se podría argumentar que el compilador de C# debe insertar esa verificación para las funciones nulas para evitar el código repetitivo en ese caso común. Pero esa decisión ahora está en el pasado, solo puedes arreglarla sin romper los programas existentes si obtienes una máquina del tiempo.

Puede utilizar los métodos de extensión (ya que pueden ser llamados en un objeto nulo) para automatizar el nulo comprobar si hay eventos:
http://blogs.microsoft.co.il/blogs/shayf/archive/2009/05/25/a-handy-extension-method-raise-events-safely.aspx
Y puesto que un parámetro es una variable temporal que no es necesario asignar manualmente el evento a una variable temporal para seguridad de hilos.

Answer 4

La razón es el rendimiento (de hecho, esa es mi mejor estimación). Los eventos y los delegados están hechos con mucha magia de compilación, cosas que no pueden ser replicadas por el simple código C#. Pero debajo hay algo como esto:

Un delegado es una clase generada por el compilador que hereda de la clase MulticastDelegate, que a su vez deriva de la clase Delegate. Tenga en cuenta que estas dos clases son mágicas y usted no puede heredarlas usted mismo (bueno, tal vez sí, pero no podrá usarlas muy bien).

Un evento sin embargo se implementa algo como esto:

private MyEventDelegateClass __cgbe_MyEvent; // Compiler generated backing field 

public event MyEventDelegateClass MyEvent 
{ 
    add 
    { 
     this.__cgbe_MyEvent = (MyEventDelegateClass)Delegate.Combine(this.__cgbe_MyEvent, value); 
    } 
    remove 
    { 
     this.__cgbe_MyEvent = (MyEventDelegateClass)Delegate.Remove(this.__cgbe_MyEvent, value); 
    } 
    get 
    { 
     return this.__cgbe_MyEvent; 
    } 
} 

bien, así que esto no es verdadero código (ni es exactamente la forma en que es en la vida real), pero debe darle una idea de lo que está pasando

El punto es que el campo de respaldo inicialmente es realmente nulo. De esta forma, no hay gastos generales para crear una instancia de MyEventDelegateClass al crear su objeto. Y es por eso que debes verificar null antes de invocar. Más adelante, cuando los manejadores se agregan/eliminan, se crea una instancia de MyEventDelegateClass y se asigna al campo. Y cuando se elimina el último controlador, esta instancia también se pierde y el campo de respaldo se restablece a nulo nuevamente.

Este es el principio de "usted no paga por lo que no usa". Mientras no uses el evento, no habrá gastos generales para él. Sin memoria extra, sin ciclos de CPU adicionales.

Answer 5

Esto puede estar indicando lo obvio, pero puede declarar su evento para apuntar a un controlador no operativo y luego no necesita comprobar nulo al invocar.

public event EventHandler MyEvent = delegate { }; 

A continuación, puede llamar a los manejadores apuntado por MyEvent sin comprobar nula.

Answer 6

"Dado que los delegados son más o menos justo una lista de funciones, yo asumiría, que esto podría haber sido fácilmente revisado por el propio delegado".

Su suposición es incorrecta. Simple y simple.

Answer 7

Internamente, el compilador generará 2 métodos add_MyEvent y remove_MyEvent para cada evento declarado en una clase. Cuando escribe, MyEvent + = ..., el compilador generará una llamada a add_MyEvent que a su vez llamará a System.Delegate.Combine.

Combinar toma 2 delegados en el parámetro y crea un nuevo delegado (multidifusión) de los 2 delegados originales, manejando el caso cuando uno de ellos es nulo (que es el caso la primera vez que llama a + =).

Supongo que el compilador podría haber sido un poco más inteligente y también manejar la llamada de evento para que cuando llame al MyEvent(), realmente generaría una verificación nula e invocaría al delegado solo si no fuera nulo. (Sería bueno tener la opinión de Eric Lippert sobre eso).