Asserts

[Gurzi]

Estive a ler sobre asserts mas não percebi bem a tradução da mesma.

Em que consiste ? Quando a devemos utilizar ?

[Knitter]

Assertion é uma técnica de programação usada para verificar se existem falhas na lógica do progama. Podes usá-la para verificar se determinadas situações ocorrem que não deviam ocorrer. No entanto devo dizer que em alguns anos de programação académica nunca usei.

Podes ler mais aqui: http://en.wikipedia.org/wiki/Assert

[Gurzi]

Obrigado Kniitter, estive a ler e dizia que é o melhor para dar rapidez ao software e para evitar e corrigir bugs.

Encontrei este link tambem .

http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

[Knitter]

É melhor para dar rapidez ao desenvolvimento do software. Facilita a detecção de erros.

[killercode]

o assert é porreiro para ser utilizado neste caso por exemplo:

tens um erro q so acontece algumas vezes..... e ainda não descubriste como reproduzi-lo... no entanto tens de lançar a aplicação para o publico em pouco tempo

metes um try{} catch{} no catch fazes disparar o assert... resultado se o utilizador conseguir reproduzir esse erro/excepção ele não vai dar por ela... ou então lanças-lhe uma mensagem de erro inesperado... no entanto enquanto tiveres a fazer debug, podes apanhar os detalhes todos do erro de uma forma tratada...

Trata-se de uma pequena ferramenta de debug!

[Dabubble]

Para que os asserts produzam algum resultado tens de os ligar (dando um argumento a JVM no arranque do teu programa) porque eles estao por default desligados.

São muito utilizados assertions para testes, nao no codigo produzido (ou seja nao sao com a keyword assert) mas sim nos teste unitarios (o JUnit providencia varios metodos para fazer assertions assim como o TestNG)

Em producao eles apenas sao utilizados (que eu tenha conecimento) para fazer testes a sistemas particulares, ou seja tens um programa complexo que depende de uma determinada arquitectura e/ou hardware, mas e dificil testar tudo a parte, o que fazes e arrancas o teu programa com as assertions ligadas (que testam ao longo do teu programa o que precisas de testar) e se tudo correr bem desligas, pois e codigo a ser executado a mais.

Importante NUNCA incluir logica do programa nas assertions.

mais informacao em: http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html#enable-disable

[Gurzi]

Então as asserts servem para existir uma comunicação entre utilizador e o software de forma a entender os erros..

Confesso que nunca percebi bem o try e catch, onde é que se pode obter um erro? Algum exemplo "básico" que eu possa perceber ? E quando usam o assert ?

Dabubble que é isso da logica do programa ?

[Knitter]

Não, os asserts servem para o programador validar a lógica de negócio, validar algoritmos, ter a certeza que determinado código faz o que é suposto.

Lógica de negócio, ou lógica de programa, como lhe quiserem chamar, são as regras que definem o software. Por exemplo, supõe que tens uma tabela que guarda o número de vacinas que uma pessoa levou, o facto de ela apenas poder levar a vacina do tetano de 10 em 10 anos nada interessa para a tabela, isso é uma regra do programa.

Código simples para testar um excepção...

public static void main(String[] args) {
    try {
        System.out.println("A lançar a excepção");
        throw new Exception("Isto é uma excepção");
    } catch (Exception ex) {
        System.out.println(ex.getMessage());
    } finally {
        System.out.println("Dentro do método finally");
    }
}

Se queres ver uma excepção que acontece quando se começa a programar tenta chamar um método de um objecto que não tenha sido iniciado, tipo:

public static void main(String[] args) {
    String strVazia;
    try {
        strVazia.lenght();
    } catch(NullPointerException ex) {
        ex.printStackTrace();
    }
}

[HecKel]

Sobre os try catchs..., depois da conversa que tive contigo no msn agora apetece-me espancar-te..., mas vou ridicularizar a situação para facilitar a compreenção, por vezes ajuda 😉

Imagina o código da estrada, são regras, é um protocolo! Mas nem todos o cumprem, algo pode correr mal..., agora imagina que és um daqueles totós que mete a vida dos outros em risco, repara neste exemplo:

try{

    andar a Xkm/h na A1

} catch(CarrodaBofia cb) {

    apanhas multa e és preso

}

Se reparares, o que está dentro da parte do try é algo arriscado que PODE dar "erro" se X >120km/h, se for esse o caso entra no catch (pena que na vida real até do catch fogem....), se for dentro dos limites faz o try na boa.

Nem todos os blocos de código necessitam de try catch, só aqueles que PREVÊS que podem dar porcaria ou por parte do utilizador, ou por outro factor externo.

abraços, HecKel

[Knitter]

Nem todos os blocos de código necessitam de try catch, só aqueles que PREVÊS que podem dar porcaria ou por parte do utilizador, ou por outro factor externo.

Para completar.... imagina que tens uma caixa de texto onde o utilizador introduz um número, podes usar excepções para verificar se o idiota do utilizador colocou uma letra, isto sem fazeres ifs ou outras validações.

No entanto não uses o mecanismo de excepções para controlar o fluxo do teu programa. E é claro que existem excepções que nunca se apanham, uma NullPointerException, por exemplo, se estiver no código, ou tens uma razão muito forte para a usares ou então estás a pensar mal a questão.

E resumo o mecanismo de excepções é usado para controlo de erros no teu programa, é um mecanismo potente, mas também algo pesado e deve ser usado com conta e medida, não vás agora substituir todos os teus ifs por blocos try-catch!

[killercode]

existem muito mais tipos de excepções q podes encontrar, Exemplos:

- Indices que ultrapassem o range de uma array

- Divisões por zero

- Casts Invalidos (imagina q queres fazes isto: (int)"Josefina" )

- etc. etc. etc.

para mais documentação acerca disso podes procurar na MSDN por Exceptions 😉

[HecKel]

os casts inválidos são erros sintácticos, esses nem o try catch safa 😞 o try catch serve para erros de runtime que o programador prevê que possam acontecer e não erros de má programação 😄 Senão eu fazia os meus programas assim:

try{

class blabla {

...

}

} catch (Exception e) {

System.err.println("Sou mesmo burro") ;

}

😄

(joke)

abraços, HecKel

[Knitter]

os casts inválidos são erros sintácticos, esses nem o try catch safa Tongue o try catch serve para erros de runtime que o programador prevê que possam acontecer e não erros de má programação Tongue

Convém referir que se usam excepções para coisas fora do controlo do programador, sockets fechados abruptamente, discos cheios, strings de utilizadores mal formadas, parametros errados em chamadas de funções por parte de outros programadores, etc.

[killercode]

imagina a situação

estas a espera de receber um valor na base de dados... e é suposto ser um inteiro.... então

int gervasio = dataReader.GetInt(0);

o valor vem DBNull... Invalid Cast Exception  😞

[Knitter]

Nesse caso é um erro de programador. Ou do que fez a base de dados e permitiu um valor null onde não devia, já que dizes que "é suposto ser inteiro", ou então do que fez o código de leitura, que se colocou a fazer suposições em vez de ler a documentação onde diz que o campo pode ter valores nulos.

Logo mau uso das excepções. Não que o mecanismo esteja a ser mal usado, a aplicação é que está mal feita 😞

[killercode]

não deixa de ser uma exception que possa ser apanhada num try{} catch{}

mas é preferivel meter a seguinte validação antes

if dataReader.IsDbNull(0)

{

blablabl

}

E fica aqui mais uma dica pos novatos 😞

[Knitter]

Realmente não deixa de ser uma excepção...

Quanto à validação, depende da aplicação, tecnologia, etc...

[HecKel]

killercode, isso eu acho que são erros que o programador NÃO DEVE considerar! Quem faz a base de dados DEVE fazer em condições e à prova de bala! E deve documentar a base de dados com diagramas de forma a facilitar a tarefa do programador.

O programador apenas se deve preocupar com o utilizador e não com os erros dos outros colegas de equipa, isso só iria prolongar a elaboração do trabalho e perder-se-ia o sentido de trabalho de grupo. Se a base de dados estiver bem documentada e bem estruturada o trabalho do programador é reduzido para metade certamente.

abraços, HecKel