Cómo utilizar Java al estilo de lanza palabra clave en C #?

Question

En Java, el throws palabra clave permite un método Declarar que no va a controlar una excepción por su propia cuenta, sino más bien tirarlo al método a llamar.

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

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

Answer 1

En Java, se debe manejar bien 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 un equivalente, como en C #, si no se controla una excepción, se formarán burbujas, hasta capturado o si no se detecta pondrá fin al programa.

Si quieres manejarlo luego volver a tirar, puede hacer lo siguiente:

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

Answer 2

El op pregunta sobre la C # equivalente de cláusula throws - no la palabra clave throw. Esto se utiliza en firmas de métodos en Java para indicar una excepción comprobada puede ser lanzado.

En C #, no hay un equivalente directo de un Java comprobado excepción. C # no tiene cláusula método de firma 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 3

Si se trata de 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 construida en la herramienta que se puede utilizar para permitir un nivel IDE "tiros" equivalente.

Si utiliza Comentarios , como se mencionó anteriormente, a continuación, se puede utilizar el < a href = "http://msdn.microsoft.com/en-us/library/w1htk11d.aspx"> etiqueta para especificar el tipo de excepción lanzada por el método o clase, así como información sobre las cuándo o por qué se tira.

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 4

Aquí está la respuesta a una pregunta similar acabo de fondo en bytes.com :

  

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

     

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

     

El más cercano que puede obtener es utilizar las etiquetas XML en su   documentación, y distribuir documentos generados NDoc con su   Código / asambleas para que otras personas puedan ver las excepciones que se lanza   (Que es exactamente lo que EM hacer en la documentación de MSDN). No se puede confiar   en el compilador para informarle sobre las excepciones no controladas, sin embargo, al igual   que se puede utilizar en Java.

Answer 5

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

1. Basándose en la documentación XML Comentarios y esperar que los demás confiar es una mala elección. La mayoría del código C # que he encontrado no hace métodos documento completo y consistente con la documentación XML Comentarios. Y luego está el problema más grande que sin excepciones comprobadas en C #, ¿cómo podría documentar todas las excepciones de su método de lanza para el propósito de su usuario API para saber cómo manejar todos individualmente? Recuerde que sólo sabe acerca de los te tiras tiro con la palabra clave en su aplicación. API que está utilizando dentro de la implementación del método también puede lanzar excepciones que no conocen porque no pueden ser documentados y no los está manejando en su aplicación, por lo que va a volar en la cara de la persona que llama de su método. En otras palabras, estos comentarios de la documentación XML hay reemplazo para excepciones comprobadas.

2. Andreas vinculado una entrevista con Anders Hejlsberg en las respuestas aquí sobre por qué el equipo de diseño de C # decidió en contra de excepciones comprobadas. 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 van a volver a cabo correctamente si se produce una excepción, pero no están realmente interesados ??en el manejo de las excepciones.

En otras palabras, nadie debe estar interesado en qué tipo de excepción se puede esperar para un API particular por lo que siempre vas a coger todos ellos en todas partes. Y si quieres que realmente se preocupan determinadas excepciones, cómo manejarlos depende de usted y no a la definición de una firma de método con algo como el Java lanza de palabras clave, lo que obliga particular, el manejo de un usuario de la API es una excepción.

-

En lo personal, estoy rota aquí. Estoy de acuerdo con Anders que tener excepciones comprobadas no resuelve el problema sin la adición de nuevos y diferentes problemas. Al igual que con los comentarios de la documentación XML, rara vez ver el código C # con todo envuelto en finalmente probar bloques. Se siente a mí, sin embargo esto es de hecho la única opción y algo que parece una buena práctica.

Answer 6

En realidad no haber excepciones controladas en C # se puede considerar una buena o mala cosa.

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

1. Las 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 juega limpio 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 manijas todas las excepciones.

Answer 7

Usted está pidiendo 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 8

Hay algunas similitudes entre el fugaces .Net CodeContract EnsuresOnThrow<> y el descriptor java throws, en que tanto puede señal 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 están garantizados para ser lanzado - esto puede ser bastante onerosos código en el método llamado si la condición de excepción no es trivial de identificar. throws Java proporciona una indicación de que excepciones podrían ser lanzados (es decir, el foco de la OMI en .NET es dentro del método que contratos para probar la throw, mientras que en Java el enfoque cambia a la persona que llama a reconocer la posibilidad de la excepción).
• .Net CC no hace la distinción entre cuadros vs sin comprobar excepciones que Java tiene, a pesar de la sección del manual CC 2.2.2 hace mención 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 hay que hacer algo , incluso si se añade un throws de la misma excepción en su interfaz.

Código de Contratos manual de aquí