As exceções são um conceito de POO?

Depois de ler um post ontem, percebi que não sabia muito sobre a origem das exceções. É apenas um conceito relacionado ao POO? Costumo pensar que sim, mas novamente existem exceções no banco de dados.

Exceções não são um conceito de POO.

Mas eles não são completamente independentes, nem em um pequeno ponto minúsculo.

Como outras respostas mostraram: O conceito de exceções chegou a vários idiomas que não são OOP. Nada nesse conceito requer algo do OOP.

Mas todas as linguagens OOP, se não todas, que levam a sério a OOP exigem exceções, porque os outros métodos de tratamento de erros falham em um ponto específico: O construtor.

Um dos pontos do POO é que um objeto deve encapsular e gerenciar seu estado interno de forma completa e consistente. Isso também significa que, em OOP puro, você precisa de um conceito para criar um novo objeto com um estado consistente "atomicamente" - tudo, desde a alocação de memória (se necessário) até a inicialização até um estado significativo (por exemplo, zerar a memória não é suficiente) deve ser feito em uma expressão. Portanto, um construtor é necessário:

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

Mas isso significa que o construtor também pode falhar devido a algum erro. Como propagar as informações de erro do construtor sem exceções?

• Valor de retorno? Falha, já que em alguns idiomas newpoderia retornar apenas, nullmas não nenhuma informação significativa. Em outras línguas (por exemplo, C ++) myFoonão é um ponteiro. Você não pode verificar null. Além disso, você não pode perguntar myFoosobre o erro - ele não foi inicializado e, portanto, "não existe" no pensamento OOP.

• Sinalizador de erro global? Tanto sobre o estado de encapsulamento e algumas variáveis ​​globais? Vá para h ... ;-)

• Uma mistura? De maneira alguma melhor.

• ?

Portanto, as exceções são um conceito mais fundamental que o POO, mas o POO se baseia nelas de maneira natural.

É apenas OOP relacionado?

Não. Exceções e POO não estão relacionadas.

O tratamento de exceções é um mecanismo para lidar com erros. Uma exceção é tratada salvando o estado atual de execução em um local predefinido e alternando a execução para uma sub-rotina específica conhecida como manipulador de exceções.

Comparando C ( não é realmente a linguagem OOP , possível de alguma forma simular exceções em C ) e C ++ (OOP, suporta exceções), nada impede o comitê padrão de C de adicionar manipulação de exceções a C, ainda não fará de C uma linguagem OOP.

Uma exceção é, simplesmente, uma situação excepcional que requer atenção e, muitas vezes, uma mudança no fluxo da execução de um programa. Por essa definição, as exceções e o tratamento de exceções não se limitam à orientação a objetos, e erros simples de programa podem ser considerados uma forma de exceção.

As linguagens orientadas a objetos geralmente têm uma classe de exceção nativa e, dependendo do contexto, a palavra "exceção" pode realmente se referir a essa classe nativa em vez do conceito geral. O tratamento de exceções orientadas a objetos é, como a maioria da orientação a objetos, açúcar sintático e pode ser facilmente emulado em linguagens decisivamente não orientadas a objetos. Aqui está um exemplo de C, no wikibook de programação 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.");
    }
}

A resposta é um simples NÃO.

Um bom exemplo para um idioma não OO com exceções é o ADA.

Algumas respostas muito boas aqui já. Outros exemplos para linguagens de programação não OOP, com exceções:

• Oracle PL / SQL

• Visual Basic clássico (V6 e abaixo, "On Error Goto" é IMHO uma forma de tratamento de exceções)

(Para ser sutil: você encontra alguns elementos OO em ambas as linguagens, mas a mecânica de manipulação de exceções não as utiliza, acho que porque o conceito foi introduzido anos antes de os elementos OO serem adicionados a essas linguagens).

A idéia básica por trás das exceções é limpar o fluxo do programa para que um programador possa seguir o caminho de execução "normal" mais facilmente. Considere um caso simples de abrir um arquivo em C. Imediatamente após tentar abrir o arquivo, o programador precisa examinar a resposta da chamada fopen () e decidir se a chamada foi bem-sucedida. Se a chamada não for bem-sucedida, o programador deverá responder adequadamente. A próxima chamada no caminho de execução "normal", talvez uma chamada para fread () ou fwrite (), apareça após o tratamento das condições de erro ou falha. Isso pode estar na próxima tela.

Com um idioma que fornece exceções, a chamada fopen () equivalente pode ser seguida imediatamente pelo fread () ou fwrite (). Não há tratamento de erros que oculte a "próxima etapa" do caminho de execução "normal". O programador pode ver mais do caminho normal em uma única tela e também pode seguir a execução mais facilmente. O tratamento de erros é movido para outra parte do programa.

Exceções em si não são um conceito de POO, mas geralmente são implementadas usando conceitos de POO que os tornam mais convenientes e poderosos. Por exemplo, as exceções podem ser definidas com uma hierarquia de herança. Usando o nosso exemplo de abertura e leitura ou gravação de um arquivo, cada uma dessas chamadas pode gerar uma variedade de exceções - FileClosedException, DeviceFullException, NoSuchFileException, InsufficientFilePermissionsException etc. Cada uma delas pode herdar de FileException, que pode herdar de IOException, que pode herdar de GenericException.

Se o programador estiver executando uma implementação rápida e suja para testar um conceito, ele poderá ignorar o tratamento de exceções e apenas implementar um único manipulador para GenericException. Esse manipulador manipulará uma GenericException e qualquer exceção que herda de GenericException. Se ele deseja tratar qualquer exceção relacionada a arquivo da mesma maneira, ele pode escrever um manipulador para FileException. Isso será chamado para FileExceptions e quaisquer exceções herdadas de FileException. Se ele quiser escrever um programa que responderá diferentemente a uma variedade de condições de erro, ele poderá escrever um manipulador específico para cada exceção específica.

Outros responderam "Não" com exemplos de idiomas. Eu pensei que poderia estender adicionando um exemplo de como adicionar exceções a um idioma sem nunca envolver OOP.

Farei isso no caso da DSKL (Declarative Sequential Kernel Language) da OZ , uma linguagem bem adequada para assuntos acadêmicos como este. O DSKL (ou DKL) pode ser visto aqui (resultado da pesquisa aleatória), a parte Declarações e Valores. A definição exata não é importante, além de ser uma linguagem muito simples, sem variáveis ​​modificáveis ​​(elas são declaradas e posteriormente vinculadas) e nenhuma OOP incorporada.

OOP não pode nem ser adicionado como uma abstração linguística a essa linguagem do kernel. Adicionando nomes exclusivos ao idioma do kernel (NewName) e usando o escopo local, o encapsulamento pode ser alcançado. Ou adicionando um estado mutável à linguagem do kernel (NewCell) e usando o escopo local OOP adequado com encapsulamento pode ser alcançado. Mas não pode ser alcançado apenas com a linguagem do kernel especificada.

Se adicionarmos exceções ao idioma do kernel, teremos um idioma sem suporte a OOP, mas teremos exceções. Deixe-me mostrar como:

Definindo uma máquina abstrata com uma pilha e um armazenamento, podemos definir o que cada declaração em nossa linguagem deve fazer (a semântica da declaração). Por exemplo, skipna pilha não deve fazer nada, A = 3na pilha deve vincular (/ unificar) A a (/ com) 3.

Começamos adicionando a sintaxe de como nossas exceções devem ser definidas. Fazemos isso adicionando mais duas cláusulas à <statement>DKL.

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

Aqui está o try / catch conhecido e uma maneira de gerar / lançar exceções.

Definimos suas semânticas pela maneira como elas devem funcionar na máquina abstrata:

Tente
A declaração semântica é: (try <statement1> catch <id> then <statement2> end)
Faça:

1. Empurre para a pilha a instrução semântica (catch <id> then <statement2> end)
2. Empurre para a pilha a instrução semântica (<statement1>)

Observe que a instrução 1 estará no topo da pilha e tentada executada primeiro.

Aumentar
A declaração semântica é (raise <id> end)
:

1. Se nada mais estiver na pilha, pare e relate uma exceção não capturada.
2. Senão, pop a primeira declaração semântica da pilha. Se não for uma declaração de captura, vá para a etapa 1.
3. Temos uma pegadinha, no formulário (catch <id> then <statement> end)
   Empurre (<statement>)para a pilha.

Catch
Se virmos uma instrução catch durante a execução normal, isso significa que tudo o que havia dentro foi executado sem gerar exceções até esse nível. Assim, apenas colocamos catcha pilha e não fazemos nada.

QED, temos um idioma com exceções e sem possibilidade de POO.

_{Eu removi a parte do ambiente da máquina abstrata para simplificá-la.}

Não.

IIRC, exceções apareceram antes dos primeiros idiomas OO. AFAIK, as exceções foram primeiro suportadas pelas implementações iniciais do LISP. Os idiomas estruturados iniciais (por exemplo, ALGOL) e os idiomas OO iniciais (por exemplo, SIMULA) não suportavam exceções.