27 março 2009

Com os relacionamentos anteriores, aprendi...

É meio estranho... Depois de Fausto ter me redigido um puta "quem sou eu" pro meu perfil do orkut, eu vim reparar no que ainda está escrito no meu "com os relacionamentos anteriores, aprendi"...

Se manter firme, quando se tem certeza que está com a razão é mais sadio do que ceder, pra manter um relacionamento. Ter a sua consciência tranquila, sabendo que todo o esforço necessário foi feito, sem passar por cima do seu amor próprio, é ainda mais gratificante...

E sim... Treinar liberdade e desapego. Como diz o blogueiro, cada mulher é inesgotável. Não a liberdade mentirosa, aquela em que por mais solto que se deixe o fruto de desejo, o pensamento ainda lhe é preso. Quase sempre se ouvirá um "não é suficiente", nas entrelinhas. Talvez um desapego total e despretencioso, aquele onde, talvez, nem a saudade lhe bata à porta...

No final disso tudo... "A gente se sente livre, ético, e o escambal"...


E é aqui que eu volto a lembrar daquilo que eu li em algum lugar... Escrever coisas num blog que nem a gente mesmo tem condições de interiorizar. É meio um misto de razão e emoção, é uma confusão só, quando a mente diz e o coração não ouve... Mas qualquer dia desses eles se entendem. Assim espero...

26 março 2009

SCJP - 05 - Exceções e Assertivas

Ando meio sem estímulo pra continuar lendo, mas como terminei o capítulo 5 faz alguns dias, estou devendo os posts/resumos pra mim mesmo :) Sendo assim, a gente continua, pontuando coisas não muito vistas e/ou importantes no que se refere a manipulação de exceções.


Nós, como bons garotos de programa, já sabemos que exceções interrompem o fluxo normal de um programa. Sabemos que é possível envolver o código passível de exceções com um bloco try/catch, ou simplesmente deixar que o método chamador cuide da exceção por nós.

try {
    //codigo que gera exceção
} catch (SomeException1 ex) { 
    //codigo que trata exceção
} catch (SomeException2 ex) {
    //codigo que trata exceção
}

public void metodo() throws SomeException{
    //codigo que gera exceção
}

O primeiro ponto importante a ser lembrado é que o código que trata a exceção (o catch) é analisado na ordem em que ele é declarado, ou seja, de cima para baixo. Imagine que uma exceção A seja superclasse de uma exceção B, e que as duas estejam sendo tratadas num bloco try/catch.

try {
    //alguma coisa
} catch (A a) {
    //outra coisa
} catch (B b) {
    //qualquer coisa
}

Se A tiver sido posicionada antes de B, ocorre um erro de compilação, cuja mensagem informa que o código que trata a exceção B nunca será alcançado. Porque? Widening... Todas as vezes que a exceção B for lançada, será tratada pelo código mais geral, ou seja, aquele que trata A, justamente porque a análise feita para encontrar um manipulador de exceções adequado é top-down.

Outra coisa curiosa é o bloco do finally. Ele é executado se a exceção for capturada ou não. Ele é executado mesmo se dentro do catch houver um return. Querem testar?


class TesteException extends Exception{}

public class Principal {

    public void teste(boolean excecao) {
        try {
            if (excecao) {
                throw new TesteException();
            }
        } catch (TesteException tex) {
            System.out.println("retornando...?");
            return;
        } finally {
            System.out.println("um momento por favor");
        }
    }

    public static void main(String[] args) {
        Principal p = new Principal();
        p.teste(false);
        System.out.println("agora sim");
        p.teste(true);
        System.out.println("agora sim");
    }
}

Lembre-se que nem o catch, nem o finally são obrigatórios, mas não deve haver um bloco try sem um catch ou um finally. Se não houver um try, e o código for passível de exceções verificadas (aquelas que não herdam de RuntimeException), tais exceções devem ser declaradas na interface publica do método, atravéz da palavra chave throws.

Não são só as exceções que alteram o fluxo de execução. Você pode fazer certas suposições, e caso elas sejam falsas, lançar algo semelhante a uma exceção, parando o fluxo de execução do programa. Isso é possível com assertivas :)

void metodo() {
    //algum código util (ou nao)

    assert(x >= 0);

    //código que assume que x seja positivo
}

Caso x seja negativo, um AssertionError (subclasse de Error) é lançado. Note que, assim como nos if, while, do, e for, a única coisa que vai entre os parêntesis do assert() é uma condicional. Qualquer coisa diferente disso gera erro de compilação. No máximo, é possivel colocar uma mensagem de erro que possa ser exibida junto com o estado atual da pilha de chamadas:

//exibindo uma string, ou qualquer coisa que 
//possa ser convertida para uma string
assert(x >= 0) : "x é negativo: " + x;

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. [Javadoc 1.6]

As assertivas só funcionam se você habilitá-las em tempo de execução, através de parâmetros passados à JVM.

java -ea pacote.Classe

ou

java -enableassertions pacote.Classe

Apesar das assertivas serem desabilitadas por padrão, é possível desabilitadas através de comandos como

java -da pacote.Classe

ou

java -disableassertions pacote.Classe

E a partir daí, é possível habilitar as assertivas em somente uma classe específica

java -ea:pacote.qualquer.Classe pacote.Principal 

Ou em um determinado pacote (e subpacotes)

java -ea:pacote.subpacote... pacote.Principal
Ou quem sabe ainda habilitá-las no geral, e desabilitalas apenas para um determinado pacote

java -ea -da:pacote.subpacote... pacote.Principal

Só fique atento para as seguintes regras:
  • Não use assertivas para validar parâmetros de métodos publicos. Como métodos públicos são a sua interface para o "mundo externo", você precisa garantir qualquer restrições quanto aos argumentos por si só.

  • Você pode usar assertivas para validar parâmetros de métodos privados. Isso parte da premissa que você pode controlar os pontos dos quais este método pode ser chamado, e a partir daí, fazer suposições coerentes.

  • Nunca use assertivas para validar parâmetros de linha de comando. Se realmente precisar validá-los, use exceções ao invés disso. Você pode pensar como se fosse algo semelhante ao primeiro item.

  • Nunca use expressões que possuam efeitos colaterais. Isso pode se referir a atribuições booleanas, métodos que retornem um booleano, coisas semelhantes.

  • Use assertivas, mesmo que em métodos públicos, para checar por código que nunca será alcançado. Note que isso é diferente do primeiro item. Um exemplo bastante simples é:

    switch(breguessu){
        case 2:
        case 4:
        case 6:
        case 8:
        case 0: break;
        default: assert(false); //assumindo que nunca 
                                 //vai passar aqui
    }
    


18 março 2009

Quem sou eu?

“A primeira pessoa com quem falei no CEFET, isso por si só já é um título e tanto... Aos poucos fui conhecendo a sua complexidade de raciocínio e sua simplicidade ao conduzir a vida. É um cara muito inteligente, atencioso, e de humor afiado. Consegue ser receptivo sob novas circunstâncias e empático com os problemas alheios.

A verdade é q o segredo da nossa longa amizade é o fato de eu me identificar com ele em 2 pontos... Somos similares, por sermos similares, somos incomuns. Pessoas anti-convencionais, de pensamentos subversivos e desafiadores. Formadores de opiniões, ações e tendências. Manipuladores do nosso destino...

Um detalhe q devo ressaltar nele, algo digno de minha inveja e admiração mútuas... É sua capacidade de se integrar e de se entregar ao momento. Ele por vezes é tão verdadeiro e intenso, q sua personalidade é algo raro no mundo. Uma pessoa q conjuga o pensar e o sentir com tanta harmonia merece a glória da eternidade.

Sfohart – True Powerful Mage. Nem Merlin é páreo... ahauhauhauahuahuahuahauhahau
”


Daeh Ero-Senin, Master of Spartan Mages...
Valeu mesmo! \o/

SCJP - 05 - Controle de Fluxo: ifs, switchs e loops

É, o capítulo 4 passou voando... E daqui a pouco eu vou precisar parar e fazer os exercícios, reler meus posts e fixar tudo o que eu li, afinal de contas, a gente já andou um bocado, não é verdade?

E o tempo realmente cura?

Dizem que o tempo é a cura pra tudo. Talvez o tempo seja o patrono de todas as curas, maior até que a penicilina, que as planas medicinais tão usadas pelos indígenas, que a resa das rezadeiras... Engraçado...


Até outro dia eu vivia lendo no msn o nick de uma amiga minha, uma frase aprecida com esta:

O tempo não cura tudo. Aliás, o tempo não cura nada, o tempo apenas tira o incurável do centro das atenções. [Martha Medeiros]

E é aí que a gente se pega em contradição. Porque nada, em questão de sentimento, tem cura... Você não sofre mais, não chora mais, não lembra mais, mas quer queira, quer não, ficou marca. E essa marca você carregará pelo resto da sua vida...

E eis que agora não é mais dor. É saudade... E o paleativo da vez é a lembrança. Das coisas boas, é claro. E daqui a algum tempo, a lembrança empoeira, fica jogada no canto do quarto da bagunça, já que um outro novo emplasto faz mais efeito...


16 março 2009

SCJP - 04 - Operadores - Notas Mentais

E finalmente eu terminei de ler o maldito capitulo 3. Caraca... Até a autora fala que o capítulo é um monstro (de chato)! E de cara, e ja inicio o capitulo 4 lendo uma coisinha que eu não tinha prestado atenção antes.


15 março 2009

SCJP - 03 - Overloading e Autoboxing

É, tem mais pegadinhas. Não fique pensando que ia se livrar fácil daquelas coisas, porque se dá pra complicar ainda mais, é isso que eles vão fazer. Conhece a Lei de Murphy?


13 março 2009

SCJP - 03 - Wrappers e Autoboxing

Talvez seja nesse item que eu tenha visto a pior pegadinha em java até agora... Eu juro que se uma questão dessa me fosse feita, eu iria errar feio. Onde ja se viu uma coisa dessas?


SCJP - 03 - Blocos de Inicialização


Bem, de novo, essa é uma das coisas que nós, programadores auto-didatas, não estamos muito acostumados a ver. Eu mesmo só inicializava as variáveis de instância ou dentro do construtor, ou logo depois de declaradas...


11 março 2009

[O Menino Amarelo] - O recepcionista.


Era uma vez um menino amarelo. E o menino amarelo gostava de frequentar lugares diferentes. Tá, tá bem, quase nunca ele faz isso por conta própria, mas sempre é válido conhecer lugares diferentes, não é verdade? Enfim, certa vez, o menino amarelo foi experimentar uma tal de cadeira erótica, sob recomendações muito bem feitas. Embrenhando-se no meio da selva de pedra, entre bares, bêbados e piriguetes de plantão, eis que ele chega são e salvo.


Entrando no recinto, um recepcionista o atende. Bem, este iria embora dali a alguns minutos, seu expediente estava quase acabando. Perguntado sobre quantas horas desejaria ficar, o menino amarelo responde em alto e bom som: 3 horas. Pega as chaves, e ainda olhando de relance pra coisas bizarras, como a rosa que vira calcinha, lá foi ele subindo as escadas.

Um quarto simples, pra não dizer demasiado humilde, com cama redonda e chuveiro pseudo-quente. Homem realmente não repara tanto em defeitos assim, mas isso, por hora, não vem ao caso. Entre estripolias e pausa pra boquinha, passaram-se duas horas. E no final dessas duas horas, alguém bate à porta.

"Ué, eu não chamei nenhuma participante a mais... É brinde do hotel?" Pensa o menino amarelo. Até que uma voz masculina surge atrás da porta. "Não, negativo, eu não pedi um participante a mais, e se isso for brinde do hotel, eu recuso!" Pensa consigo mesmo, de novo, o menino amarelo.

- Senhor? acabou o tempo...
- Mas como assim acabou o tempo? Eu pedi três horas!
- Perdão senhor, o outro recepcionista não me alertou desse detalhe...

E lá se vai o empata-foda do turno. Pronto, adeus concentração. E olá olhos aguçados para mais defeitos. "Eita, tem alguma coisa me coçando... Ah achei, ta aqui, voando bem na minha frente. Porra, até mosquito aqui tem!" E com as duas mãos, estapeou a muriçoca, que esvaiu-se em sangue. "Eita poooooooha, tem uma baratinha andando ali no chão! Véio, que poha é essa?"... Corre, corre, menino amarelo, pega o seu chinelo e pisa em cima da barata!

Depois de brincar mais um pouco, rindo muito por dentro, acabam-se as três horas. Chegando à recepção, o que se vê é uma ameba super desenvolvida, fundida geneticamente com células de pus, acometidas de febre amarela, dengue, rubéola e cachumba (tá, coloca meningite e leptospirose no meio, pra ficar parecida com o samba). Sim, era com isso que se parecia o recepcionista de plantão. E naquele mesmo instante, iniciou-se um trololó sobre a atuação quase exótica do recepcionista, que deve ter tomado curso de atendente de lan house. Poha, passou do tempo, paga adicional! "Mas é que quando passam da hora, a gente fala do adicional, e só querem pagar pelas horas normais, sem o atraso".

E diante de uma das folhas de sugestão, uma caneta se movia avidamente, rabiscando tudo com zero, zero, zero, zero... Aquela noite realmente vai pra história...