¿Son las excepciones un concepto OOP?

Después de leer una publicación ayer, me di cuenta de que no sabía mucho sobre el origen de las excepciones. ¿Es solo un concepto relacionado con OOP? Tiendo a pensar que sí, pero de nuevo hay excepciones en la base de datos.

Las excepciones no son un concepto OOP.

Pero tampoco están completamente ajenos en un pequeño punto.

Como han mostrado otras respuestas: el concepto de excepciones lo ha hecho en varios idiomas que no son OOP. Nada en ese concepto requiere algo de OOP.

Pero cualquiera, si no todos los lenguajes OOP que toman en serio OOP requieren excepciones porque los otros métodos de manejo de errores fallan en un punto específico: el constructor.

Uno de los puntos de OOP es que un objeto debe encapsular y administrar su estado interno de manera completa y consistente. Esto también significa que en OOP puro necesita un concepto para crear un nuevo objeto con un estado coherente "atómicamente": todo, desde la asignación de memoria (si es necesario) hasta la inicialización a un estado significativo (es decir, la puesta a cero simple de la memoria no es suficiente) hacerse en una sola expresión. Por lo tanto, se requiere un constructor :

Foo myFoo = Foo("foo", "bar", 42);

Pero esto significa que el constructor también puede fallar debido a algún error. ¿Cómo propagar la información del error desde el constructor sin excepciones?

• Valor de retorno? Falla ya que en algunos idiomas newsolo puede devolver nullinformación significativa, pero no ninguna. En otros lenguajes (por ejemplo, C ++) myFoono es un puntero. No se pudo comprobarlo null. Además, no puede preguntar myFoosobre el error: no está inicializado y, por lo tanto, "no existe" en el pensamiento OOP.

• ¿Indicador de error global? ¿Tanto sobre el estado de encapsulación y luego alguna variable global? Ve a h ... ;-)

• ¿Una mezcla? De ninguna manera mejor.

• ?

Por lo tanto, las excepciones son un concepto más fundamental que OOP, pero OOP se basa en ellas de forma natural.

¿Está relacionado solo con POO?

No. Las excepciones y la POO no están relacionadas.

El manejo de excepciones es un mecanismo para manejar errores. Una excepción se maneja guardando el estado actual de ejecución en un lugar predefinido y cambiando la ejecución a una subrutina específica conocida como controlador de excepciones.

Comparando C ( no realmente el lenguaje OOP , es posible emular excepciones de alguna manera en C ) y C ++ (OOP, admite excepciones), nada impide que el comité estándar de C agregue el manejo de excepciones a C, todavía no hará que C sea un lenguaje OOP.

Una excepción es, simplemente, una situación excepcional que requiere atención y, a menudo, un cambio en el flujo de la ejecución de un programa. Según esa definición, las excepciones y el manejo de excepciones no se limitan a la orientación a objetos, y los errores simples del programa pueden considerarse una forma de excepción.

Los lenguajes orientados a objetos suelen tener una clase de excepción nativa y, según el contexto, la palabra "excepción" podría referirse a esa clase nativa en lugar del concepto general. El manejo de excepciones orientado a objetos es, como la mayoría de la orientación a objetos, azúcar sintáctica, y puede emularse fácilmente en lenguajes decididamente no orientados a objetos. Aquí hay un ejemplo de C, del wikibook de Programación en C :

#include <stdio.h>
#include <setjmp.h>

jmp_buf test1;

void tryjump()
{
    longjmp(test1, 3);
}

int main (void)
{
    if (setjmp(test1)==0) {
        printf ("setjmp() returned 0.");
        tryjump();
    } else {
        printf ("setjmp returned from a longjmp function call.");
    }
}

La respuesta es un simple NO.

Un buen ejemplo para un lenguaje no OO con excepciones es ADA.

Algunas muy buenas respuestas aquí ya. Otros ejemplos para lenguajes de programación que no son OOP que tienen excepciones:

• Oracle PL / SQL

• Visual Basic clásico (V6 y abajo, "On Error Goto" es en mi humilde opinión una forma de manejo de excepciones)

(Para ser meticuloso: encuentra algunos elementos OO en ambos idiomas, pero la mecánica de manejo de excepciones no los utiliza, supongo que porque el concepto se introdujo años antes de que los elementos OO se agregaran a esos idiomas).

La idea básica detrás de las excepciones es limpiar el flujo del programa para que un programador pueda seguir la ruta de ejecución "normal" más fácilmente. Considere un caso simple de abrir un archivo en C. Inmediatamente después de intentar abrir el archivo, el programador necesita examinar la respuesta de la llamada fopen () y decidir si la llamada tuvo éxito. Si la llamada no tuvo éxito, entonces el programador debe responder adecuadamente. La siguiente llamada en la ruta de ejecución "normal", quizás una llamada a fread () o fwrite (), aparecerá después de que se hayan manejado las condiciones de error o falla. Eso puede estar en la siguiente pantalla.

Con un lenguaje que proporciona excepciones, la llamada a fopen () equivalente puede ser seguida inmediatamente por fread () o fwrite (). No hay manejo de errores que esté ocultando el "siguiente paso" de la ruta de ejecución "normal". El programador puede ver más de la ruta normal en una sola pantalla y, por lo tanto, puede seguir la ejecución más fácilmente. El manejo de errores se mueve a otra parte del programa.

Las excepciones en sí mismas no son un concepto de OOP, pero a menudo se implementan utilizando conceptos de OOP que los hacen más convenientes y potentes. Por ejemplo, las excepciones pueden definirse con una jerarquía de herencia. Utilizando nuestro ejemplo teórico de abrir y leer o escribir un archivo, cada una de esas llamadas puede generar una variedad de excepciones: FileClosedException, DeviceFullException, NoSuchFileException, InsufficientFilePermissionsException, etc. Cada una de ellas puede heredar de FileException, que puede heredar de IOException, que puede heredar de GenericException.

Si el programador está haciendo una implementación rápida y sucia para probar un concepto, puede ignorar la gestión de excepciones y simplemente implementar un controlador único para GenericException. Ese controlador manejará una GenericException y cualquier excepción que herede de GenericException. Si quiere tratar cualquier excepción relacionada con archivos de la misma manera, puede escribir un controlador para FileException. Eso se llamará para FileExceptions y cualquier excepción que herede de FileException. Si quiere escribir un programa que responda de manera diferente a una variedad de condiciones de error, puede escribir un controlador específico para cada excepción específica.

Otros han respondido correctamente "No" con ejemplos de idiomas. Pensé que podría extender agregando un ejemplo sobre cómo agregar excepciones a un idioma sin involucrar a OOP.

Lo haré en el caso del DSKL (lenguaje de núcleo secuencial declarativo) de OZ , un lenguaje muy adecuado para cosas académicas como esta. El DSKL (o DKL) se puede ver aquí (resultado de búsqueda aleatorio), la parte de declaraciones y valores. La definición exacta no es importante, aparte de ser un lenguaje muy simple sin variables modificables (se declaran y luego se vinculan), y sin OOP incorporado.

OOP ni siquiera se puede agregar como una abstracción lingüística a este lenguaje kernel. Al agregar nombres únicos al idioma del kernel (NewName) y usar el alcance local, se puede lograr la encapsulación. O agregando un estado mutable al lenguaje del núcleo (NewCell) y utilizando el alcance local, se puede lograr una OOP adecuada con encapsulación. Pero no se puede lograr solo con el lenguaje del núcleo especificado.

Si luego agregamos excepciones al idioma del kernel, tendremos un idioma sin soporte de OOP pero tendremos excepciones. Déjame mostrarte cómo:

Al definir una máquina abstracta con una pila y un almacenamiento, podemos definir qué debe hacer cada declaración en nuestro lenguaje (la semántica de la declaración). Por ejemplo, skipen la pila no se debe hacer nada, A = 3en la pila se debe unir (/ unificar) A a (/ con) 3.

Comenzamos agregando la sintaxis de cómo deberían definirse nuestras excepciones. Hacemos esto agregando otras dos cláusulas <statement>en el DKL.

<statement>  ::== ... (old stuff)
                 | try <statement> catch <id> then <statement> end
                 | raise <id> end

Aquí está el conocido try / catch, y una forma de aumentar / lanzar excepciones.

Definimos su semántica por cómo deberían funcionar en la máquina abstracta:

Probar
La declaración semántica es: (try <statement1> catch <id> then <statement2> end)
Hacer:

1. Empuje sobre la pila la declaración semántica (catch <id> then <statement2> end)
2. Empuje sobre la pila la declaración semántica (<statement1>)

Tenga en cuenta que la declaración 1 estará en la parte superior de la pila y se intentó ejecutar primero.

Elevar
La declaración semántica es: (raise <id> end)
Hacer:

1. Si no hay nada más en la pila, deténgase e informe una excepción no detectada.
2. De lo contrario, haga estallar la primera declaración semántica de la pila. Si no es una declaración catch, vaya al paso 1.
3. Tenemos una trampa, en el formulario (catch <id> then <statement> end)
   Empuje (<statement>)hacia la pila.

Captura
Si vemos una instrucción catch durante la ejecución normal, esto significa que todo lo que se ejecutó en el interior sin generar excepciones hasta este nivel. Por lo tanto, solo sacamos catchla pila y no hacemos nada.

QED, tenemos un lenguaje con excepciones y sin posibilidad de OOP.

_{He eliminado la parte del entorno de la máquina abstracta para simplificarla.}

No.

IIRC, las excepciones aparecieron antes de los primeros idiomas OO. AFAIK, las primeras implementaciones de LISP respaldaron las excepciones. Los primeros lenguajes estructurados (por ejemplo, ALGOL) y los primeros idiomas de OO (por ejemplo, SIMULA) no admitían excepciones.