Excepciones vs Valores de devolución especiales

Question

¿Cuál es una mejor práctica en programación?

No estoy hablando de total exclusividad. Es más para cosas como:

list<T>.Find, donde obtiene default(T) o su valor, en lugar de la excepción ValueNotFound (ejemplo).

o

list<T>.IndexOf, donde se obtiene -1 o el índice correcto.

Answer 1

Bueno, la respuesta es que depende.

En el caso de que un artículo no se encuentre en una lista, lanzar una excepción es una práctica horrible, porque es completamente posible que el artículo no esté en la lista.

Ahora bien, si esto era una lista especializada de algún tipo, y el artículo debe absolutamente se encuentra en la lista, a continuación, que debe lanzar una excepción, ya que se ha encontrado con una situación que no era factible/razonable.

En términos generales, para cosas como las reglas de negocios y similares, los códigos de error especializados son mejores, porque usted es consciente de la posibilidad de que esto ocurra y desea reaccionar a esas posibilidades. Las excepciones son para los casos que no espera y no puede continuar con la ejecución del código si se producen.

Answer 2

Desde una perspectiva puramente de diseño, prefiero arrojar excepciones cuando sucede algo "excepcional", p. la clave que pediste no fue encontrada. La razón principal es que hace la vida más fácil para el consumidor: no tienen que verificar el valor después de cada llamada a su función. También me gustan las funciones TrySomething, porque luego el usuario puede probar explícitamente si la operación fue exitosa. Desafortunadamente las excepciones en .Net son bastante caras (desde mi experiencia normalmente tardan unos 50 ms en arrojar una), así que desde la perspectiva práctica puede devolver uno de estos valores predeterminados en lugar de arrojar una excepción, especialmente en la programación GUI .

Answer 3

Creo que es ligeramente situacional, pero se rige más por si el evento de devolución es en realidad una excepción lógica o no. El ejemplo de indexOf es una respuesta de salida perfectamente normal donde -1 es lo único que tiene sentido (o nulo para los tipos de referencia).

Una excepción debería ser exactamente eso: excepcional, lo que significa que desea todo el seguimiento y manejo de la pila que puede obtener de una excepción real.

Answer 4

En los casos que mencionaste preferiría el valor de retorno ya que sé exactamente qué hacer con eso. Y no hay razón para molestarse con atrapar en el mismo ámbito.

Por supuesto, si su lógica está construida de manera que los valores siempre deben estar en la lista y su ausencia es el error de lógica del programador, las excepciones son la manera.

Answer 5

Viniendo de un fondo de Java, prefiero las excepciones en la mayoría de los casos. Hace que su código sea mucho más limpio cuando la mitad no se gasta en comprobar los valores devueltos.

Dicho esto, también depende de la frecuencia con la que es probable que algo "falle". Las excepciones pueden ser costosas, por lo que no desea tirarlas innecesariamente por cosas que con frecuencia fallarán.

Answer 6

Una excepción debería ser algo "excepcional". Entonces, si llamas a Find, y esperas encontrar algo, no importa qué, entonces lanzar una excepción si no encuentras algo es un buen comportamiento.

Si, sin embargo, es el flujo normal, que a veces no encuentras algo, entonces lanzar una excepción es malo.

Answer 7

Más eficaz C# por Bill Wagner hizo una excelente recomendación en lo que respecta a las excepciones. La idea es seguir adelante y lanzar una excepción al realizar una operación, solo asegúrese de proporcionar ganchos para verificar si el valor generará una excepción.

Por ejemplo

// if this throws an exception 
list.GetByName("Frank") // throws NotFound exception 
// provide a method to test 
list.TryGetByName("Frank") // returns false 

esa manera se puede optar por la excepción escribiendo algo así como

MyItem item; 
if (list.TryGetByName("Frank")) 
    item = list.GetByName("Frank"); 

Answer 8

Una regla de oro es usar excepciones sólo cuando sucede algo que "no debe ocurrir".

Si esperaría que una llamada a IndexOf() no encontrara el valor en cuestión (una expectativa razonable), entonces debería tener un código de retorno para eso (probablemente -1 como usted dice). Algo que nunca debería fallar, como la asignación de memoria, debería arrojar una excepción en un caso de falla.

Otra cosa para recordar es que el manejo de excepciones es "costoso" en términos de rendimiento. Por lo tanto, si su código maneja regularmente las excepciones como parte de las operaciones normales, no funcionará tan rápido como podría.

Answer 9

se puede disfrutar de mi serie del blog de dos partes que se analiza una gran cantidad de ventajas y desventajas aquí dependiendo de qué características admite el lenguaje de programación, ya que parece bastante relevante:

An example of the interplay between language features and library design, part one

An example of the interplay between language features and library design, part two

Agregaré que creo que muchas de las respuestas a esta pregunta son deficientes (he votado negativamente a muchas de mis cohortes). Especialmente malo son las API a lo largo de las líneas de

if (ItWillSucceed(...)) { 
    DoIt(...) 
} 

que crean todo tipo de problemas infeliz (ver mi blog para más detalles).

Answer 10

Como en muchas cuestiones relacionadas con la programación, todo depende ...

Me parece que uno realmente debe primero tratar de definir su API casos excepcionales por lo que no pueden suceder en el primer lugar.

Usar Design By Contract puede ayudar a hacer esto. Aquí uno insertaría funciones que generan un error o falla e indican un error de programación (no error del usuario). (En algunos casos, estas comprobaciones se eliminan en el modo de lanzamiento).

Luego, mantenga excepciones para fallas genéricas que no se pueden evitar, como la conexión de DB falló, la transacción optimista falló, la escritura de disco falló.

Por lo general, no es necesario capturar estas excepciones hasta que lleguen al "usuario". Y provocará que el usuario tenga que volver a intentarlo.

Si el error es un error del usuario como un error tipográfico en un nombre o algo, entonces trate eso directamente en el código de la interfaz de la aplicación. Dado que este es un error común, necesitaría ser manejado con un mensaje de error amigable al usuario potencialmente traducido, etc.

La aplicación de capas también es útil aquí. Así que vamos a tomar el ejemplo de traslación de efectivo de una cuenta de una otra cuenta:

transferInternal(int account_id_1, int account_id_2, double amount) 
{ 
    // This is an internal function we require the client to provide us with 
    // valid arguments only. (No error handling done here.) 
    REQUIRE(accountExists(account_id_1)); // Design by contract argument checks. 
    REQUIRE(accountExists(account_id_2)); 
    REQUIRE(balance(account_id_1) > amount); 
    ... do the actual transfer work 
} 

string transfer(int account_id_1, int account_id_2, double amount) 
{ 
    DB.start(); // start transaction 
    string msg; 
    if (!checkAccount(account_id_1, msg)) return msg; // common checking code used from multiple operations. 
    if (!checkAccount(account_id_2, msg)) return msg; 
    if (!checkBalance(account_id_1, amount)) return msg; 
    transferInternal(account_id_1, account_id_2, amount); 
    DB.commit(); // This could fail with an exception if someone else changed the balance while this transaction was active. (Very unlikely but possible) 
    return "cash transfer ok"; 
} 

Answer 11

He leído en alguna parte una buena regla sobre esto que me gusta mucho. Dice: "una función debe arrojar una excepción si y solo si no puede realizar la tarea para la que estaba destinado".

Entonces, lo que suelo hacer es decidir qué debe hacer una función (que generalmente proviene de requisitos comerciales o algo así), y luego lanzar excepciones para todo lo demás.

Si ha diseñado bien su aplicación, sus funciones serán bastante pequeñas y realizará tareas relativamente simples con valores de retorno simples. Decidir sobre excepciones por la regla anterior no será difícil.

Por supuesto, siempre hay casos ambiguos (como con una clave que no se encuentra en un diccionario). Esos deben ser lejanos e intermedios, pero allí solo tendrá que usar su intuición sobre cuál es la solución más elegante.

Ah, y con todo esto, nunca lo olvides: para que esto funcione bien, solo puedes atrapar excepciones que puedes procesar. Sobre todo, eso significa que los atrapará solo en los niveles superiores de UI, donde puede mostrarlos al usuario y registrarlos o algo así. Los niveles inferiores pueden usar bloques finally o volver a lanzar excepciones después de algún procesamiento propio, pero las excepciones capturadas genuinamente en niveles bajos generalmente indican un diseño incorrecto.

Answer 12

¿Qué prefieres usar?

A:

item = list.Find(x); 

B:

If (list.Contains(x)) 
    item = list.Find(x); 
else 
    item = null; 

C:

try { 
    item = list.Find(x); 
} 
catch { 
    item = null; 
} 

estoy dispuesto a apostar que la respuesta es A. Por lo tanto, en este caso de regresar por defecto (T) es la elección correcta.

Answer 13

Los mejores idiomas le permiten hacer lo que se ajuste a sus necesidades. Al igual que en Smalltalk-80:

A continuación se lanzará una excepción si no hay usuario para el id:

user := userDictionary at: id 

Éste evaluará el bloque dado que es una función de alto nivel:

user := userDictionary at: id ifAbsent: [ 
    "no such id, let's return the user named Anonymous" 
    users detect: [ :each | each name = 'Anonymous' ] ] 

Tenga en cuenta que el método real es: ifAbsent :.

Answer 14

Para el primero, que no me gusta mucho la opción default(T): ¿y si usted tiene una lista de int donde 0 (presumiblemente esto es por defecto int 's; yo no uso C#) es un valor perfectamente permisible?

(Disculpas por la sintaxis de Java, pero si trataba de adivinar C# probablemente me hacen un lío de ella en alguna parte :))

class Maybe<T> { 
    public Maybe() { 
     set = false; 
     value = null; 
    } 

    public Maybe(T value) { 
     set = true; 
     this.value = value; 
    } 

    public T get(T defaultVal) { 
     if (set) 
      return value; 
     return defaultVal; 
    } 

    private boolean set; 
    private T value; 
} 

Luego, por supuesto Find devolvería un Maybe<T>, y la persona que llama elige algún valor que sea un valor predeterminado en este contexto. Quizás podría agregar getDefault como un método conveniente para cuando default(T)es la respuesta correcta, por supuesto.

Para IndexOf, -1 es un valor razonable para esto, ya que los valores válidos obviamente siempre son> = 0, así que simplemente lo haría.

Answer 15

Lo que suelo hacer en este caso es definir una clase de opción (inspirada en F #) y extender IEnumerable con un método TryFind() que devuelve la clase Option.

public class Option<T> 
{ 
    string _msg = ""; 
    T _item; 

    public bool IsNone 
    { 
     get { return _msg != "" ? true : false; } 
    } 

    public string Msg 
    { 
     get { return _msg; } 
    } 

    internal Option(T item) 
    { 
     this._item = item; 
     this._msg = ""; 
    } 

    internal Option(string msg) 
    { 
     if (String.IsNullOrEmpty(msg)) 
      throw new ArgumentNullException("msg"); 

     this._msg = msg; 
    } 

    internal T Get() 
    { 
     if (this.IsNone) 
      throw new Exception("Cannot call Get on a NONE instance."); 

     return this._item; 
    } 

    public override string ToString() 
    { 
     if (this.IsNone) 
      return String.Format("IsNone : {0}, {1}", this.IsNone, typeof(T).Name); 

     else 
      return String.Format("IsNone : {0}, {1}, {2}", this.IsNone, typeof(T).Name, this._item.ToString()); 
    } 

}

A continuación, puede utilizarlo como

var optionItem = list.TryFind(x => trueorFalseTest()); 
if (!optionItem.IsNone) 
    var myItem = optionItem.Get(); 

De esta manera, si existe o no el artículo, la colección es atravesada sólo una vez.