switch - ¿Cómo se usa el estilo Java arroja la palabra clave en C#?

console.setcursorposition 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

Aquí hay una respuesta a una pregunta similar que acabo de financiar en bytes.com :

La respuesta corta es no, no hay excepciones marcadas en C #. El diseñador del lenguaje discute esta decisión en esta entrevista:

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

Lo más cercano que puede obtener es usar las etiquetas en su documentación XML y distribuir documentos generados por NDoc con su código / ensambles para que otras personas puedan ver qué excepciones arroja (que es exactamente lo que hace MS en la documentación de MSDN). Sin embargo, no puede confiar en el compilador para informarle sobre las excepciones no controladas, como es posible que esté acostumbrado en Java.

Answer 2

Después de leer la mayoría de las respuestas aquí, me gustaría agregar un par de ideas.

1. Confiar en los comentarios de documentación XML 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 hacer excepciones marcadas. La última respuesta a la pregunta original está oculta en esa entrevista:

Los programadores protegen su código escribiendo "try finally" en todas partes, por lo que retrocederán correctamente si ocurre una excepción, pero en realidad no están interesados ​​en manejar las excepciones.

En otras palabras, nadie debería estar interesado en qué tipo de excepción se puede esperar de una API en particular, ya que siempre las va a 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.

Answer 3

En Java, debe manejar una excepción o marcar el método como uno que puede lanzarlo usando 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 desea manejarlo, vuelva a lanzar puede hacer lo siguiente:

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

Answer 4

En realidad, no haber verificado las excepciones en C # puede considerarse algo bueno o malo.

Yo mismo lo considero una buena solución, ya que las excepciones comprobadas le proporcionan los siguientes problemas:

1. Excepciones técnicas que se escapan a la capa de negocio / dominio porque no puede manejarlas correctamente en el nivel bajo.
2. Pertenecen a la firma del método que no siempre juega bien con el diseño de API.

Debido a eso en la mayoría de las aplicaciones más grandes, verá el siguiente patrón a menudo cuando se verifique. Se producen excepciones:

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

Lo que esencialmente significa emular la forma en que C # / .NET maneja todas las excepciones.

Answer 5

Hay algunas similitudes fugaces entre .Net CodeContract EnsuresOnThrow<> y el descriptor java throws , en el sentido de que ambos pueden indicar al llamante el tipo de excepción que podría surgir de una función o método, aunque también hay diferencias importantes entre 2:

• EnsuresOnThrow<> va más allá de solo indicar qué excepciones se pueden lanzar, pero también estipula las condiciones bajo las cuales se garantiza que se lanzarán: 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 se pueden lanzar (es decir, IMO, el foco en .Net está dentro del método que se contrae para demostrar 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, aunque la sección de manual CC 2.2.2 hace mención a

"use postcondiciones excepcionales solo para aquellas excepciones que un llamante debe esperar como parte de la API"

• En .Net, la persona que llama puede determinar si hace o no algo con la excepción (por ejemplo, desactivando contratos). En Java, el llamador debe hacer algo , incluso si agrega throws para la misma excepción en su interfaz.

Manual de Contratos de Código aquí

Answer 6

La operadora pregunta por el equivalente de C # de la cláusula throws 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 hay 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 a

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

Answer 7

Sí, este es un hilo viejo, sin embargo, con frecuencia encuentro hilos viejos cuando busco respuestas, así que pensé que agregaría algo útil que encontré.

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

Si usa Comentarios de documentación XML , 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 8

Usted está preguntando sobre esto:

Relanzar 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
}