LP 26/10/2011

   # # # # # # # # # # # # # #
  # Linguagens de Programação #
  # Prof. Fernando Pereira    #
  # notasdogarcia.blog.com    #
   # # # # # # # # # # # # # #

		// A aula começou falando sobre como retornar um erro em uma função de tipo estatico?

Solução 1:
  Reservar um valor para erro. Como por exemplo retornar 0 ao desempilhar uma pilha vazia de inteiros.

  Problemas:
    Isso pode causar confusão.

Solução 2:
  Utilizar um flag de erro.

  Problemas do uso de flags:
    Não há nada que force o programador a ler o flag, então é perigoso.

Solução 3:
  Usar uma guarda, que deve ser chamada antes de se realizar a chamada da função para verificar se está tudo ok.

  Problemas:
    Gasto exacerbado de processamento, já que é preciso verificar a cada uso.

Solução 4:
  Terminar o programa.

  Problemas o código fica pouco modular, já que quem vai usar isso pode não querer que o programa termine.

Que solução um compilador poderia nos dar para tratar esses erros?

Sol. de Compilador 1:
  Ao declarar uma função voce pode colocar as requisições necessárias para seu funcionamento.
  E as requições necessárias quanto ao tipo de retorno para garantir que o retorno foi válido.

  Vantagens:
    Tudo é garantido pelo compilador, assim o usuário não precisa se preocupar com isso.

Sol. de Compilador 2:
  - Tipagem, não aceitar tipos inválidos.

Sol. de Compilador 3:
  - Contratos,

Sol. de Compilador 4:
  - Exceções (checked = Java)

Sol. de Compilador 5:
  - Visilibidade

Sol. de compilador
  - Anotações

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Exemplo de exceção em SML:

exception BadArgument of int;

fun fact n =  if n=0 then 1 else n * fact(n-1)

Agora se o parâmetro for -1 isso dará loop infinito.

Como corrigir esse problema?

fun fact1 n = if n<0 then raise BadArgument n else fact n;

fun usefact1 n =
  "Resp: " ^ int.toString(fact n)
  handle BadArgument n => "Erro: " ^ Int.toString n;

E pronto temos uma função mais segura.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Para haverem exceções é preciso de 3 coisas:

  Definir exceções.

  Disparar exceções.
  ex: raise, throw

  Tratar exceções.
  ex: handle, catch except

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

exceções em python:

Class ArithmeticException(Exception):
  def __init__(self, msg):
    self.value = msg
  def __str__(self):
    return repr (self.value)

def div(n,d):
  if d == 0:
    raise ArithmeticException("Erro: " + str(n))
  else:
    return n/d

while True:
  try:
    n = float(raw input("Dividendo: "))
    d = float(raw input("Divisor: "))
    r = div(n,d)
    print r
  except ValueError:
    print "Não eh numero!. Tente novamente: "
  except ArithmeticException, ae:
    print ae.value

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Em java:

public class TE
{
  public static void main(String[] args)
  {
    try
    {
      int i = Integer.parseInt(args[0]);
      int j = Integer.parseInt(args[1]);
      System.out.println( i/j );
    }
    catch(ArrayIndexOutOfBoundsException aie) { System.out.println("Deu pau na divisao por zero"); }
    catch(ArithmeticException ae) { System.out.println("Deu pau na divisao por zero"); }
  }
}

// Uma exceção em java volta destruindo e imprimindo as funções destruidas na tela. ( quando se está debugando )
// Assim aparecem várias menssagens.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Em java as exceções e erros são classes na forma:

  Object

  Error extend object implements Throwable,   Exception extend object implements Throwable

  "Checked" extende Exception,     runtimeExceptioin herda de Exception

  "cacheBad" extende Exception.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  // Exception é portanto mãe de todos os outros erros. e um catch Exception é capaz de receber qualquer erro.
  // Em java não coloque um catch exception antes de outros catchs pois isso torna o código dos demais catchs inalcansável, e isso da erro de compilação.

  Qualquer erro que extenda exception diretamente (ao invés de herdar de RuntimeException) necessáriamente precisa ser tratado., Se não for o programa encerra com erro.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

// Houveram vários exemplos de exceções em java.

  Pergunta:
    Porque nem todas as exceções são obrigatóriamente tratadas?

  Porque isso é custoso, em termos de legibilidade do código, pode até ser que o código fique mais denso com tratamentos do que com código.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  O professor mostrou que uma exceção estaticamente verificada deve ser verificada na declaração da função com a o nome "throws(exp1, exp2)"


  // Em resumo tava com sono, a aula foi sobre gramática de chamada de exceções e catchs em java.
  // finally é uma coisa chamada após o bloco de um catch, e dentro do bloco do finally as coisas são executadas imediatamente antes do try terminar.

// fim da aula.