Patent BR-112015015648-A2 (BR)
Title: aprimoramento de sistemas de software por minimização de lógica de recuperação de erro
Inventor: ALEXANDER D BROMFIELD
IPC: G06F11/36
Filed: 2014-01-03
Abstract: relatório descritivo da patente de invenção para "aprimoramento de sistemas de software por minimização de lógica de recuperação de erro". antecedentes [001] computadores e sistemas de computação têm afetado quase todos os aspectos da vida moderna. os computadores são envolvidos, em geral, em trabalho, recreação, cuidados de saúde, transporte, entretenimento, gestão doméstica, etc. a funcionalidade de computador é tipicamente o resultado de sistemas de computação que executam código de software. [002] uma porção substancial de código de software moderno é dedicada a descobrir, relatar e recuperar a partir de condições de erro. em cenários do mundo real, as condições de erro são relativamente raras e são frequentemente difíceis de simular, no entanto, programadores devotam uma quantidade substancial de recursos para lidar com as mesmas. [003] dentro de sistemas de software, existe uma quantidade desproporcional de bugs em código de recuperação de erro quando comparado ao código total nesses sistemas. isso correlaciona diretamente ao fato de que condições de erro são frequentemente difíceis de simular e como resultado frequentemente seguem não testadas até que um cliente encontre a questão subjacente no campo. lógica de recuperação de erro inapropriada pode levar a erros compostos e em última instância a falhas fatais e corrupção de dados. [004] sistemas de software tradicionais misturam tipos diferentes de condições de erro e fornecem um mecanismo único para lidar com essas condições de erro. essa uniformidade é atraente na superfície uma vez que permite que desenvolvedores raciocinem sobre condições de erro de uma forma única consistente para o sistema. infelizmente, essa uniformidade ofusca diferenças qualitativas em erros. [005] a matéria reivindicada no presente documento não é limitada a modalidades que solucionam quaisquer desvantagens ou que operam apenas em ambientes tais como aqueles descritos acima. preferivelmente, esses antecedentes são fornecidos apenas para ilustrar uma área de tecnologia exemplificativa em que algumas modalidades descritas no presente documento podem ser praticadas. sumário [006] uma modalidade pode ser um método praticado em um ambiente computacional com decisões de tratamento de erros. o método inclui identificar um conjunto que inclui uma pluralidade de condições de falha identificadas explicitamente. o método inclui adicionalmente determinar que uma ou mais das condições de falha identificadas explicitamente tenha ocorrido. como resultado, o método inclui adicionalmente interromper um primeiro escopo de execução de computação predeterminado e notificar outro escopo de computação da condição de falha. [007] uma modalidade alternativa pode ser praticada em um ambiente computacional e inclui um método para tratar erros. o método inclui identificar um conjunto que inclui uma pluralidade de condições de falha identificadas explicitamente. o método inclui adicionalmente determinar que uma condição de erro tenha ocorrido que não está no conjunto que inclui uma pluralidade de condições de falha identificadas explicitamente. como resultado, o método inclui adicionalmente interromper um primeiro escopo de execução de computação predeterminado e notificar outro escopo de computação da condição de erro. [008] esse sumário é fornecido para introduzir uma seleção de conceitos de uma forma simplificada que são descritos adicionalmente abaixo na descrição detalhada. esse sumário não é destinado a identificar recursos chave ou recursos essenciais do objeto reivindicado, tampouco o mesmo é destinado a ser usado como um auxílio na determinação do escopo do objeto reivindicado. [009] recursos e vantagens adicionais serão apresentados na descrição a seguir, e em parte ficarão óbvios a partir da descrição ou poderão ser aprendidos através da prática dos ensinamentos no presente documento. os recursos e as vantagens da invenção podem ser percebidos e obtidos por meio dos instrumentos e combinações indicados particularmente nas reivindicações anexas. os recursos da presente invenção serão demonstrados mais plenamente a partir da descrição a seguir e das reivindicações anexas ou poderão ser aprendidos através da prática da invenção como apresentada doravante. breve descrição dos desenhos [0010] a fim de descrever a maneira pela qual as vantagens e os recursos enumerados acima e outros podem ser obtidos, uma descrição mais particular do objeto descrito brevemente acima será apresentada por referência a modalidades específicas que são ilustradas nos desenhos anexos. entende-se que esses desenhos retratam apenas modalidades típicas e, portanto, não devem ser considerados como limitantes ao escopo, as modalidades serão descritas e explicadas com especificidade e detalhes adicionais através do uso dos desenhos anexos nos quais: [0011] a figura 1 ilustra um escopo de computação de execução; [0012] a figura 2 ilustra um corpo de código e compilação do código com um compilador; [0013] a figura 3 ilustra um sistema de código gerenciado; [0014] a figura 4 ilustra um método para tratar erros; e [0015] a figura 5 ilustra outro método para tratar erros. descrição detalhada [0016] as modalidades dividem explicitamente todas as condições de falha nas que são consideradas "esperadas" e "inesperadas". é esperado que o software se recupere in situ de falhas esperadas, enquanto que falhas inesperadas são manipuladas externamente. isso é feito devido ao fato de que, por definição, as falhas são inesperadas e o software não está preparado para a falha. as modalidades podem incluir um ou mais dentre uma quantidade de mecanismos diferentes para tornar possível para um ambiente de software identificar sistematicamente quais falhas são esperadas e quais são não, de modo que possa acontecer a disposição correta. com referência à figura 1, as modalidades podem dividir todo o conjunto de condições de erro 102 que ocorre dentro de um escopo de execução de software 100 em dois tipos e fornecer mecanismos especializados para lidar com cada tipo. ao fazê-lo, as modalidades derivam uma quantidade de benefícios que varia de correção aprimorada a desempenho aprimorado. com referência à figura 1, os dois tipos amplos de modalidades de condições de erro reconhecidos são condições recuperáveis internamente 104 e condições recuperáveis externamente 106. [0017] as condições recuperáveis internamente 104 são condições de erro em que um escopo de execução de software 100 tem a capacidade de descobrir e recuperar confiavelmente de dentro do escopo local de uma computação. esses erros se originam a partir de duas fontes amplas: falhas de i/o e falhas semânticas. [0018] as condições recuperáveis externamente 106 são condições para as quais as modalidades determinam que o software é mal equipado para tratar in situ e, portanto, são tratadas por um agente externo 108. as condições de erro recuperáveis externamente se originam, em geral, a partir de duas fontes amplas: defeitos de software (ou seja, bugs) e meta-falhas (por exemplo, incapacidade para alocar memória). uma meta-falha é uma falha que não é relacionada diretamente às semânticas de uma computação e é o resultado de uma restrição em um ambiente virtual no qual a computação executa. por exemplo, uma computação espera ter uma pilha sobre a qual a mesma pode colocar variáveis locais. se um ambiente virtual impuser um limite à profundidade de uma pilha, uma computação não tem, em geral, a capacidade de prever quando esse limite ocorrerá e não tem nenhum percurso de recuperação possível quando tal limite é alcançado. de maneira similar, as computações tipicamente esperam para ter a capacidade de alocar memória e a incapacidade de obter nova memória é uma meta-falha. [0019] quando esses erros ocorrem, o escopo de computação 100 no qual o erro ocorreu terá sido de alguma forma comprometido e, portanto, não tem a capacidade de tratar as condições de erro e se recuperar das mesmas. o tratamento de erro é, assim, deixada para um agente externo 108 que opera em um escopo não comprometido 110. por exemplo, no caso de incapacidade para alocar memória, solicitar um agente no escopo de computação original 100 que não pode alocar memória para começar um algoritmo de recuperação pode resultar frequentemente em o agente tentar alocar memória para realizar o algoritmo de recuperação. isso faz pouco sentido. em vez disso, um agente externo 108 que tenha a capacidade de alocar memória ou que já tenha memória alocada para recuperação pode ter uma capacidade melhor para tratar o erro. [0020] uma resposta comum para "memória esgotada" é de fato renunciar à operação completamente. enquanto que códigos de sistemas tradicionais que enfrentam uma condição de memória esgotada contêm necessariamente uma quantidade substancial de verificações de erro e lógica de remoção extensiva para limpeza em caso de falha, em modalidades do presente documento o código pode ser escrito como se a alocação sempre fosse bem sucedida. se uma alocação falhar, então as modalidades param imediatamente de executar qualquer código adicional e transferem para outro contexto que pode, então, tratar toda a operação como tendo falhado. [0021] uma quantidade de código substancial em sistemas tradicionais existe para fornecer detecção, relato e recuperação de tempo de execução local fundamentalmente inconsistentes de condições de erro. esse código pode ocasionalmente ter êxito, mas frequentemente o mesmo é um exercício de futilidade. algumas modalidades reveladas no presente documento sistematicamente renunciam a esse código, o que resulta em código fonte consideravelmente menor não sobrecarregado com lógica de remoção sujeita a erro. [0022] as modalidades combinam uma quantidade de técnicas para dividir sistematicamente condições de erro nos dois tipos acima e para habilitar programadores a raciocinar explicitamente sobre qual código pode e não pode falhar. aplicando-se sistematicamente essas técnicas, as modalidades obtêm benefícios consideráveis de tempo de correção, desempenho e desenvolvimento. [0023] a seguir, é ilustrado um breve sumário de diversos aspectos de uma ou mais das várias modalidades reveladas no presente documento. as modalidades, como descrito acima, podem implantar a divisão de tipo de erro. as modalidades podem sistematicamente dividir todas as condições de erro em erros recuperáveis internamente 104 e erros recuperáveis externamente 106 e aplicar políticas de disposição explicitamente diferentes para cada uma. [0024] as modalidades podem implantar um conceito referido no presente documento como abandono. o abandono é um mecanismo para suspender imediatamente a execução de uma computação dentro de um escopo corrompido, tal como, por exemplo, o escopo de execução de software 100. um processo de sistema operacional serve como um escopo de contexto de abandono típico, mas, como ilustrado em mais detalhe abaixo, outros são possíveis. quando ocorre abandono, nenhum código adicional executa dentro do escopo da computação, o que impede que corrupção adicional seja introduzida e permite que um agente externo tente recuperação como alternativa. [0025] as modalidades podem implantar contratos holísticos com abandono. os sistemas podem definir uma metodologia de projeto baseada em contrato. algumas modalidades reveladas no presente documento introduzem o uso de contratos em um sistema operacional, alavancando contratos para definir todas as interfaces de sistema operacional adicionalmente para usar contratos dentro de sua implantação. um contrato define um conjunto de exigências estáticas invariáveis que um agente lógico requer. por exemplo, um contrato pode definir entradas aceitáveis no agente lógico. se qualquer uma das exigências estáticas invariáveis não for atendida, o contrato é violado. as modalidades estendem o modelo de contrato clássico tratando-se violações de contrato como sendo situações que não podem ser corrigidas pelo violador ou pelo agente lógico ao qual o contrato se aplica, o que transforma essas violações em erros recuperáveis externamente 106. [0026] as modalidades podem implantar um tempo de execução gerenciado com abandono. enquanto que sistemas de linguagem gerenciados tradicionais, tais como java e c#, contam com exceções para relatar falhas em nível de tempo de execução, tais como acesso a matriz fora de limites, desreferência nula ou condições de memória esgotada, as modalidades tratam todas essas ocorrências como violações das pré-condições de contrato do tempo de execução que levam a abandono. [0027] as modalidades podem implantar exaustão de memória com abandono. enquanto que sistemas tradicionais tentam relatar sistematicamente todas as formas de exaustão de memória para o programador, algumas modalidades reveladas no presente documento tratam essas ocorrências como não sendo recuperáveis internamente e consequentemente as mesmas são apenas erros recuperáveis externamente 106 que levam ao abandono da computação atual. [0028] as modalidades podem implantar um sistema de efeito de exceção para condições de erro recuperáveis internamente. o uso das modalidades de mecanismos acima pode reduzir dramaticamente a quantidade de software que precisa de lógica de recuperação para condições de erro recuperáveis internamente. isso torna possível introduzir um sistema de efeito para tornar explícito para o programador e compilador quais métodos e blocos de código podem experimentar erros recuperáveis como ilustrado pelo código que não pode falhar 202 na figura 2 e quais não podem como ilustrado pelo código que pode falhar 204 ilustrado na figura 2. em algumas modalidades, os métodos e blocos código podem ser anotados com metadados que indicam se os mesmos podem se recuperar internamente ou não. isso permite que representações gráficas de chamada grandes dentro de sistema e código de aplicação sejam escritos com o pressuposto de ausência de erros internos. isso torna o código afetado, consideravelmente mais fácil de escrever e raciocinar a seu respeito, e aprimora a capacidade para análise estática para descobrir defeitos no software que poderiam levar a condições de erro recuperáveis externamente 106. a seguir, é ilustrado um exemplo de anotação de código. esse exemplo mostra que métodos podem ser declarados como lançando exceções. quando não anotado dessa maneira, um método não pode lançar exceções e consequentemente não experimenta ou induz quaisquer erros recuperáveis internamente. como resultado, chamadas para o método são tratadas como infalíveis e não requerem nenhuma lógica de recuperação de erro. entretanto m2 é anotado como lançando, e consequentemente chamadas para esse método têm que necessariamente ser precedidas pela palavra chave 'tentar' para indicar para o programador um ponto potencial de falha. adicionalmente, uma vez que a chamada pode falhar, é necessário que lógica de recuperação de erro seja contida na cláusula de catch. // a method that doesn't produce recoverable errors void m1() { } // a method that may produce recoverable errors throws void m2() { } ... { // this call can not fail m1(); try { // this call can fail, as denoted by the 'try' keyword try m2(); } catch { // implement recovery logic for m2's failure } } [0029] as modalidades podem experimentar desempenho aprimorado. os compiladores obtêm oportunidades para otimizações ao alavancar as semânticas específicas de abandono e do sistema de efeito de exceção. adicionalmente, há menos código escrito pelo desenvolvedor em afunilamentos, o que tende a aprimorar a eficácia de caches de instrução de microprocessador. [0030] detalhes adicionais são ilustrados agora. [0031] a distinção entre condições de erro recuperáveis internamente 104 e condições de erro recuperáveis externamente 106 define como algumas modalidades reveladas no presente documento são construídas. as modalidades reconhecem essa dualidade em diferentes níveis do sistema e alavancam a mesma como um princípio guia quando se considera funcionalidade do sistema. [0032] as condições de erro recuperáveis internamente 104 surgem a partir de duas fontes amplas. uma é a partir de falhas i/o. os sistemas de computador realizam operações de i/o 112 para dispositivos externos tais como discos rígidos 114 ou adaptadores de rede 116 e essas operações 112 são falíveis inerentemente. os controladores de disco 114 podem falhar, cabos de rede podem ser desconectados, etc. as operações de i/o 112 são realizadas tipicamente em um software de sistema em um nível relativamente bruto, que as credita para lógica de recuperação de erro. [0033] a segunda fonte de erros recuperáveis internamente são falhas semânticas. essas ocorrem em seguida a uma operação de i/o 112 quando novos dados 118 entram no sistema. o formato e tamanho de dados de entrada 118 são usualmente sujeitos a uma variedade de restrições 120 e quando essas restrições 120 são violadas, uma falha semântica terá ocorrido. como as falhas de i/o, as falhas semânticas são uma parte esperada de consumo de quaisquer dados e o software é, em geral, bem equipado para descobrir, relatar e se recuperar das mesmas. [0034] para se recuperar confiavelmente de falhas de i/o ou falhas semânticas, em algumas modalidades, o software assume que meta-falhas e defeitos de software não existem. o software é considerado ser defeituoso quando o mesmo não se comporta de acordo com o previsto. defeitos podem ficar aparentes para o usuário do software em virtude de término inesperado do software (ou seja, uma falha fatal) ou através de saída errônea de alguma forma. o software pode descobrir defeitos por si mesmo, estabelecendo que certa invariável tem que se manter e verificar que as mesmas estão realmente se mantendo por toda a execução do software. logicamente é inconsistente assumir que se possa escrever lógica de recuperação robusta quando a própria lógica de recuperação é sujeita a falhas que a mesma não pode controlar. [0035] uma condição de erro recuperável externamente 106 é uma que é ou devido a um bug no software ou devido a uma questão ambiental fora do controle da computação ou do escopo de execução de software 100 que experimenta o erro. a condição de erro é manipulada externamente por um agente externo 108 quando o erro tiver deixado o escopo de execução de software 100 em um estado comprometido fundamentalmente e, consequentemente, não tem a capacidade de se recuperar logicamente por si próprio. os sistemas tradicionais rotineiramente permitem que essas computações comprometidas tentem se recuperar de erros, o que leva às questões de metaestabilidade endêmicas aos sistemas de software de grande escala modernos. [0036] os sistemas de software incluem várias formas de validação empírica de condições que se acredita verdadeiras em qualquer ponto no tempo durante a vida do sistema, ou seja, as invariáveis descritas acima. quando essa validação falha, isso indica que um bug no software foi detectado. como não há nada que uma computação possa fazer para se recuperar de bugs em seu próprio código, as modalidades consideram essas situações como apenas sendo condições recuperáveis externamente 106. [0037] agora com referência à figura 3, ambientes gerenciados executam software 302 sobre uma máquina virtual 304. a máquina virtual 304 pode experimentar falhas que são completamente alheias às semânticas da computação 306 que está sendo executada. as modalidades chamam essas de meta-falhas. por exemplo, um compilador jit 308 pode incorrer em memória esgotada quando tenta compilar dinamicamente parte de um código da computação. essas falhas desafiam recuperação interna uma vez que o programador não tem a capacidade de raciocinar sobre o estado da máquina virtual 304. qualquer código de recuperação poderia o próprio ser sujeito às mesmas falhas. [0038] as condições de erro recuperáveis internamente 104 podem se beneficiar de grande precisão. semanticamente, os programadores podem frequentemente entender exatamente o que leva ao erro. em contrapartida, as condições de erro recuperáveis externamente 106 são imprecisas por natureza. quando uma computação encontra uma condição de erro recuperável externamente 106, a computação (executando em um escopo de execução 100) é terminada através de abandono e uma computação distinta (por exemplo, um agente externo 108) é notificada e espera-se que realize suas tarefas de recuperação. como a mesma o faz, a computação externa está frequentemente ciente apenas das entradas de nível mais alto para a computação abandonada e não tem acesso à causa específica do erro. [0039] a perda de precisão é realmente útil para reduzir a quantidade da lógica de tratamento de erro e para aprimorar sua qualidade. modalidades substituem uma grande quantidade de identificação de erro interno refinada, que é reportado para ser recuperado por lógica externa. isso leva a uma redução considerável na quantidade de código fonte escrito e é inerentemente muito mais fácil para os desenvolvedores tratarem. [0040] fundamentalmente, quando os desenvolvedores escrevem código é quase impossível raciocinar sobre todas as possíveis falhas e todas as possíveis estratégias de recuperação. o ambiente gerenciado tradicional faz com que quase toda instrução de programa seja suscetível à falha ocasional e seres humanos não conseguem pensar nesses termos. algumas modalidades reveladas no presente documento reduzem dramaticamente a quantidade de lógica de recuperação que precisa ser escrita, e como alternativa requer que a mesma seja escrita para executar em um contexto que é conhecido por ser confiável. confrontação de tipos de erro [0041] essa tabela ilustra as diferenças entre os dois tipos de erro que as modalidades podem definir: erros recuperáveis internamente erros recuperáveis externamente origem exemplificativa falhas de i/o - não pode encontrar um arquivo - conexão de rede perdida - abandono de processo filho falhas semânticas - formato de arquivo inválido - entrada de usuário inválida imprecisões de software - violação de implicação - violação em tempo de execução meta falhas - exaustão de memória - overflow de pilha estado de computação normal, pode continuar executando comprometido, deve parar a execução frequência comum e esperada em sistemas normais. rara, sinais de que algo ruim está acontecendo. partições de programação efeito da exceção para o sistema. implicações - pré-condições - pós-condições - asserções [0042] o abandono representa a cessação imediata e irreversível de atividade dentro de um escopo de execução específico 100. um escopo de execução 100 é definido como um conjunto fechado de localizações de memória acessível a partir de uma computação executando dentro do escopo. os escopos de execução podem ser de várias granularidades diferentes. por exemplo, um escopo de execução pode ser um processo e consequentemente o abandono leva ao término do processo. alternativamente, um escopo de execução pode ser um grupo de processos de modo que modalidades possam abandonar o grupo de processos. alternativamente, o escopo de execução pode ser a máquina na qual um ou mais processos é implantado de modo que o sistema como um todo possa abandonar (levando a uma reinicialização) se um erro não recuperável for encontrado. em outro exemplo alternativo, um escopo de execução pode existir dentro de um processo, mas não é o processo inteiro. em outra alternativa, o escopo de execução pode ser um escopo personalizado definido que cruza escopos de execução tradicionais. quando o abandono tiver ocorrido, a computação é interrompida e o escopo de execução é reciclado pelo ambiente. [0043] como ilustrado acima, em algumas modalidades, um escopo de execução é um processo. entretanto, uma determinação de escopo apropriado pode ser se o mesmo está equipado para se recuperar da falha de outro escopo. dado algum escopo a que tenta responder à falha de algum escopo b, os recursos usados tanto por a como por b são suficientemente isolados para que a falha em b não interfira negativamente com a operação do escopo a. se for esse o caso, as modalidades podem considerar a falha para aplicar a um escopo ainda maior (por exemplo, toda a máquina em vez de apenas um processo). [0044] o escopo de execução 100 envolvido no abandono, em algumas modalidades representa o conjunto total de localizações de memória que uma computação pode ter mudado da hora em que uma condição de erro recuperável externamente tiver ocorrido até o ponto em que a condição de erro foi reconhecida e o abandono foi disparado. parando-se imediatamente a computação, as modalidades impedem que corrupção se espalhe adicionalmente. quando uma computação é abandonada, sua falha é relatada para uma computação distinta (ilustrada como o agente externo 108) dentro de um escopo ortogonal 110 não afetado pelas mutações do primeiro escopo. essa computação distinta então é responsável por decidir sobre um curso de recuperação. [0045] algumas modalidades podem ser implantadas em um ambiente com uma arquitetura de contrato holístico com abandono. diversos sistemas de software usam a metodologia de projeto baseada em contrato na qual a linguagem de programação eiffel foi pioneira disponibilizada pela eiffel software de goleta, califórnia. algumas modalidades reveladas no presente documento são projetadas sistematicamente ao redor de uma metodologia de contrato. em algumas modalidades, virtualmente cada parte do sistema é especificada e implantada com declarações de contrato. por exemplo, como ilustrado na figura 1, o contrato pode ser incorporado pelas restrições 120. a seguir é ilustrado o uso de pré-condições e pós-condições de contrato para codificar restrições em um sistema de software. // declaring a method int compute(int x) requires x > 0 // a constraint on the caller of the method ensures return != 0 // a constraint on the implementation of the method { } ... { // invoking the method int y = compute(-l); // violates the precondition constraint int z = compute(l); // satisfies the precondition constraint // due to the 'ensures' clause above, at this point z is known to be != 0 // (not equal to zero) } [0046] a metodologia de projeto de contrato permite que o programador a especifique restrições 120 sobre os valores e combinação de valores que abstrações de software individuais podem manter. essas restrições 120 complementam aquelas já impostas pelo tipo de sistema. por exemplo, uma pré-condição de contrato pode especificar que um dado parâmetro do método deve estar na faixa de 0 a 31, o que é uma restrição sobre todos os valores possíveis que um parâmetro inteiro normal poderia ter. [0047] em sistemas típicos, violações de contrato resultam em alguma forma de condição de erro recuperável internamente visível para a computação. por exemplo, em exceções de lançamento (throw) de violações de contrato de eiffel. em algumas modalidades reveladas no presente documento, as modalidades visualizam uma violação de contrato como representando um bug no software, efetivamente um desacordo entre dois componentes sobre suas obrigações mútuas. por sua natureza os bugs de software não são recuperáveis in situ uma vez que um programador pode precisar ser envolvido para mudar o código fonte de alguma forma. como resultado, em algumas modalidades reveladas no presente documento as violações de contrato são tratadas como sendo apenas condições recuperáveis externamente 106 e consequentemente as mesmas levam a abandono. [0048] a ampla maioria de verificações de correção feitas em um sistema operacional em torno de limites de interface de programação de aplicação (api) é para proteger contra erros de programador. o sistema operacional faz uma verificação para a condição ruim e retorna uma indicação de falha para o chamador. o chamador também faz, então, algumas verificações caso a operação tenha falhado. toda essa verificação representa muito código que causa impacto na legibilidade, no tempo de desenvolvimento e no desempenho do sistema resultante. [0049] um exemplo de código c típico que demonstra a dupla verificação é como segue: bool m 1 (int x) { // a check in the implementation if (x < 0) { return false; } ... return true; } void m2() { if (ml (42) == false) { // another check in the caller } } [0050] em algumas modalidades reveladas no presente documento, o código nunca raciocina localmente sobre a recuperação de violações de contrato, a eliminação daquela lógica de todos os códigos programas e sistema reduz inerentemente o tamanho de programa e aprimora o desempenho: void m1(int x) requires x >= 0 // a single check { } void m2() { m1 (42); } [0051] como ilustrado na figura 3, algumas modalidades implantam um tempo de execução gerenciado com abandono. as linguagens gerenciadas fornecem salvaguardas para impedir alguns comportamentos inesperados no software. por exemplo, a segurança de tipo garante que ponteiros sempre referenciem dados fortemente tipados válidos. em um ambiente gerenciado típico tal como java ou .net, tentativas pelo software de violar uma