¿Cómo usar el estilo de Java arroja la palabra clave en C#?

Question

En Java, la palabra clave throws permite que un método declare que no manejará una excepción por sí mismo, sino que la lanzará al método de llamada.

¿Hay una palabra clave/atributo similar en C#?

Si no hay un equivalente, ¿cómo se puede lograr el mismo efecto (o uno similar)?

Answer 1

En Java, debe manejar una excepción o marcar el método como uno que puede arrojarlo utilizando la palabra clave throws.

C# no tiene esta palabra clave o una equivalente, como en C#, si no maneja una excepción, se disparará, hasta que se atrape o si no se captura, terminará el programa.

Si quieres manejarlo continuación, volver a tirar, puede hacer lo siguiente:

try 
{ 
    // code that throws an exception 
} 
catch(ArgumentNullException ex) 
{ 
    // code that handles the exception 
    throw; 
} 

Answer 2

Usted está preguntando por esto:

Re-lanzar una excepción

public void Method() 
{ 
    try 
    { 
     int x = 0; 
     int sum = 100/x; 
    } 
    catch(DivideByZeroException e) 
    { 
     throw; 
    } 
} 

o

static void Main() 
    { 
     string s = null; 

     if (s == null) 
     { 
      throw new ArgumentNullException(); 
     } 

     Console.Write("The string s is null"); // not executed 
    } 

Answer 3

Aquí es una respuesta a una pregunta similar acabo Fondo sobre bytes.com:

La respuesta corta es no, no hay excepciones comprobadas en C#. El diseñador de la lengua discute esta decisión en esta entrevista:

http://www.artima.com/intv/handcuffs.html

El más cercano que puedes conseguir es utilizar las etiquetas en la documentación XML y distribuir NDoc genera documentos con sus código/conjuntos que por lo para que otras personas puedan ver qué excepciones arrojas (que es exactamente lo que MS hace en la documentación de MSDN). No puede confiar en el compilador para informarle acerca de las excepciones no controladas, sin embargo, como que puede estar acostumbrado en Java.

Answer 4

En realidad, no haber verificado las excepciones en C# puede considerarse una cosa buena o mala.

yo mismo considero que es una buena solución, ya que excepciones comprobadas le proporcionan los siguientes problemas:

1. excepciones técnicas fugas a la capa de negocio/dominio porque no se puede manejar de manera adecuada en el nivel bajo.
2. Pertenecen a la firma del método que no siempre funciona bien con el diseño de la API.

Debido a que en la mayoría de las aplicaciones más grandes, verá el siguiente patrón de frecuencia cuando se producen excepciones controladas:

try { 
    // Some Code 
} catch(SomeException ex){ 
    throw new RuntimeException(ex); 
} 

Lo que significa esencialmente que emula la forma en C# NET/Palancas todas las excepciones..

Answer 5

El op pregunta sobre la C# equivalente de throws clause de Java - no la palabra clave throw. Esto se usa en las firmas de métodos en Java para indicar que se puede lanzar una excepción marcada.

En C#, no existe un equivalente directo de una excepción marcada de Java. C# no tiene una cláusula de firma de método equivalente.

// Java - need to have throws clause if IOException not handled 
public void readFile() throws java.io.IOException { 
    ...not explicitly handling java.io.IOException... 
} 

se traduce en

// C# - no equivalent of throws clause exceptions are unchecked 
public void ReadFile() 
{ 
    ...not explicitly handling System.IO.IOException... 
} 

Answer 6

Sí, esto es un hilo de edad, sin embargo, me encuentro con frecuencia viejos hilos cuando estoy buscando en Google respuestas así que pensé que añadiría algo útil que he encontrado.

Si está utilizando Visual Studio 2012, hay una herramienta incorporada que se puede usar para permitir un nivel IDE "throws" equivalente.

Si usa XML Documentation Comments, como se mencionó anteriormente, puede usar la etiqueta <exception> para especificar el tipo de excepción arrojada por el método o clase, así como información sobre cuándo o por qué se lanza.

ejemplo:

/// <summary>This method throws an exception.</summary> 
    /// <param name="myPath">A path to a directory that will be zipped.</param> 
    /// <exception cref="IOException">This exception is thrown if the archive already exists</exception> 
    public void FooThrowsAnException (string myPath) 
    { 
     // This will throw an IO exception 
     ZipFile.CreateFromDirectory(myPath); 
    } 

Answer 7

Hay algunas similitudes fugaces entre el .Net CodeContract EnsuresOnThrow<> y el descriptor java throws, en que tanto puede indicar a la persona que llama como el tipo de excepción que podría ser levantado de una función o método, aunque también hay grandes diferencias entre el 2:

• EnsuresOnThrow<> va más allá de simplemente indicando las excepciones que pueden ser lanzadas, sino que también establece las condiciones en las que son gua surgió para ser lanzado - este puede ser un código bastante oneroso en el método llamado si la condición de excepción no es trivial para identificar. Java throws proporciona una indicación de qué excepciones podrían lanzarse (es decir, IMO, el foco en .Net está dentro del método que contrae para probar el throw, mientras que en Java el foco se desplaza a la persona que llama para reconocer la posibilidad de la excepción).
• .Net CC no hace la distinción entre Checked vs Unchecked excepciones que Java tiene, a pesar de la sección del manual CC 2.2.2 menciona a

"utilizar poscondiciones excepcionales sólo para aquellas excepciones que la persona que llama debe esperar como parte de la API"

• En .Net la persona que llama puede determinar si debe o no hace nada con la excepción (por ejemplo, mediante la desactivación de los contratos). En Java, la persona que llama must do something, incluso si agrega un throws para la misma excepción en su interfaz.

Code Contracts manual here

Answer 8

Después de pasar por la mayor parte de las respuestas aquí, me gustaría añadir un par de reflexiones.

1. Confiar en la documentación XML Los comentarios y esperar que otros confíen es una opción pobre. La mayoría del código de C# que he encontrado no documenta los métodos de forma completa y coherente con los comentarios de la documentación XML. Y luego está el problema más grande: sin excepciones comprobadas en C#, ¿cómo podría documentar todas las excepciones que arroja su método para que su usuario API sepa cómo manejarlas individualmente? Recuerda, solo sabes sobre los que te arrojas con la palabra clave throw en tu implementación. Las API que está utilizando dentro de la implementación de su método también pueden arrojar excepciones que no conoce porque podrían no estar documentadas y no las está manejando en su implementación, por lo que explotarán ante la persona que llama. método. En otras palabras, estos comentarios de documentación XML no reemplazan las excepciones marcadas.

2. Andreas relacionó una entrevista con Anders Hejlsberg en las respuestas aquí sobre por qué el equipo de diseño de C# decidió no marcar excepciones. La respuesta definitiva a la pregunta original se oculta en esa entrevista:

Los programadores proteger su código escribiendo intento por último está en todas partes, por lo que va a realizar una copia correctamente si se produce una excepción, pero no son realmente interesado en manejar las excepciones.

En otras palabras, a nadie debería interesarle qué tipo de excepción se puede esperar para una API en particular, ya que siempre las encontrará en todas partes. Y si realmente desea preocuparse por excepciones particulares, la forma de manejarlas depende de usted y no de alguien que defina una firma de método con algo como la palabra clave Java throws, lo que obliga a un manejo de excepciones particular en un usuario API.

-

Personalmente, estoy desgarrado aquí. Estoy de acuerdo con Anders en que haber verificado las excepciones no resuelve el problema sin agregar problemas nuevos y diferentes. Al igual que con los comentarios de la documentación XML, rara vez veo el código C# con todo incluido en los bloques try finally. A mí me parece que, de hecho, esta es su única opción y algo que parece una buena práctica.