Programação

Notação Infixa, Posfixa, Conversão.

Posted in Java, Math, Programação, TDD Problems on August 18th, 2010 by Edipo L Federle – 2 Comments

[UPDATE 20 Agosto 2010]

Nesses ultimo dias tinha criado uma classe para resolver as expressões na notação posfixa, segue o link do github:

http://github.com/edipofederle/PostfixEvaluation

Olá esse post irá ser um pouco diferente do que venho escrevendo por aqui, esse é um assunto assim digamos mais teórico(realmente a palavra não é essa), enfim, vou falar um pouco aqui sobre a notação Infixa e Posfixa, e também sobre o algoritmo para resolver uma conversão de infixa para posfixa.

Notação Infixa

Notaçao infixa é quando na expressão temos os operedatores binários colocados entre os operandos, ou seja o que estamos mais acostumados a fazer. Algo como:Sabemos que nessas expressões as vezes se faz necessário o uso de paranteses para nao ocorrer ambiguidade.(regras de prioridade). Por exemplo:NOTA #1: Estou considerando apenas oprações binárias.

Esse tipo de expressão torna o trabalho computacional muito mais complicado.

Notação Posfixa

Notação posfixa é aquela onde os operadores estão localizados após os operandos, dessa forma não se faz preciso parenteses. Por exemplo, a expressão acima ficaria assim:Simplificamos bem a expressão escrevendo ela de forma posfixa.

Convertendo Expressões de Infixa para Posfixa

Árvore de expressão Binária

Uma árvore de expressão binária nos mostra de forma clara a precedencias e a associetividade dos operadores em uma expressão, dada a expressão na notação infixa:temos a seguinte árvore de expressão:

Agora dada uma expressão na forma posfixa:temos a seguinte árvore de expressão:

Se avaliarmos essa expressão de forma “Postorder Traversal” iremos ter a expressão na forma posfixa.

Algoritmo

A conversão de infixa para Posfixa é feita usando uma técnica chamada operator precedence parsing, precisamos usar a estrutura de dados do tipo pilha(stack), o algoritmo funciona da seguinte forma.

Data um expressão infixa faça:

– Add um parenteses esquerdo ‘(‘ na pilha;
- Add um parenteses direito ‘)’ à expressão infixa;
- Enquanto a pilha não estiver vazia ler a expressão infixa da esquerda para a direita e então:
- se o caractere lido por um digito(ou variavel) -> então add na saida(posfixa);
- se o caractere lido por um parenteses esquerdo ‘(‘-> entao add na pilha;
- se o caractere for um operador entao faça:
- Enquanto operador no topo da pilha tiver precedencia igual ou maior que a do operador lido -> Remove operador do topo da pilha.
- add o caractere atual a pilha;
- se o caractere aqual for um parenteses direito ‘)’;
- enquanto não achar um parenteses esquerdo ‘(‘ no topo da pilha faça:
-> Remover operador do tipo da pilha e add a saida(posfixa)
-> remover e descartar o parenteses esquerdo ‘(‘;

Código Java

Baixo segue o link para o github onde esta a classe para em Java para conversão, vale lembrar que acabei por escrever esse post pois encontrei esse problema no site TDD Problems que por sinal recomendo a todos para práticar TDD e programação, tem problemas bem legais lá, desde coisas simples até complexas, entao de uma olhada no código que escrevi para esse problemas, não sei o quão bom esta, mas esta com todos testes de unidade passando :D , tentei deixar a classe bem limpa, clara e pequena, as funções estão pequenas, mas acho que não é o bastante ainda, podemos simplificar bem mais, alguns métodos estão um pouco feios também(necessita de mais refatoração certamente).

A classe é dividida nos seguintes métodos:

converterToPostFix(String infix)
removeFromStackUntilFindRightParenthesis(String postfix)
isADigit(String digit)
isOperator(String ch)
precedence(String top, String ex)

Acredito que os nomes estão bastante sugestivos quanto as suas responsabilidades.

Código Fonte: http://github.com/edipofederle/InfixToPostfixConverter

É isso pessoal, espero que tenha sido útil para alguem, e deixe-me saber de qualquer problema com esse código, podem criticar :D (mas fazm fork e arrumem a sujeira :D ).

Até Logo.

Deploy de Aplicações Rails Usando Git – Gem Gploy

Posted in Deploy, GIT, Open Source, Programação, Ruby/Rails on July 31st, 2010 by Edipo L Federle – Be the first to comment

Este post irá descrever de forma mais completa o que a gem gploy faz, acredito que não será um post grande pois a gem não faz tanta coisa assim. :D Gploy é uma RubyGem que pode ser usada para configurar seu projeto Ruby on Rails e seu servidor para realizar deploy usando git. De forma alguma quero tentar substituir ou algo assim gems muito melhores e eficientes como o Imploy ou o locarails, até mesmo pois essas fazem o trabalho de outra forma.

Resumo

Gploy é uma Gem Ruby simples para configurar e fazer deploy de apps Rails, essa gem foi escrita por min(Edipo), o codigo não esta elegente como deveria, mas estou trabalhando nisso :D .

O que preciso ter.

Se faz necessário o uso de git para controle de versão de seu projeto Rails, o que acredito que seja praticamente impossível alguem do Rails não esta usando git para versionamento, você também precisa um servidor web(sério?) que rode Ruby on Rails, até agora somente testei na locaweb, pois essa gem faz o uso de uma estrutura de pasta em particular que é encontrada nos servidores da locaweb(mas imagino que outros servidores não são diferentes disso), outra coisa muito importante é que, novamente, até o momento, essa gem faz o uso de um repositório git no mesmo servidor que irá esta hospedada a aplicação, então seu servidor também precisa ter suporte a git. Dito isso, a estrutura de pasta que o gploy usa é a seguinte:

~/repos -> Repositorio git
~/rails_app -> Onde fica seu projeto de produção
~/public_html -> Aqui irá ser criado um link simbólico com a aplicação.

Logo a pasta repos poderá ser substituída por qualquer uma de sua preferencia atras de uma configuração adicional.

Que arquivos são usados

Os comandos gploy -c e gploy -pr geram dois arquivos, config/config.yaml e config/post-receive respectivamente. O primeiro é um arquivo yaml que guarda as informação do seu servidor, nome da app e origin(git).

Acho que não tem muito o que falar sobre esse arquivo ele é auto-explicativo, apenas tome cuidado com a ultima linha(origin) caso você já tenha no seu git um origin configurado use outro nome. Caso você tenha um key ssh configurada para seu servidor na sua maquina e não necessite senha simplesmente deixa essa opção em branco.

O segundo arquivo é o post-receive que é um hook do git, basicamente falando é um arquivo que é executado sempre que o repositório em questão sofre algum tipo de ação, no nosso caso é quando ele recebe um push, esse arquivo se parece com isso:

Esse conteúdo é o que é gerado pelo gploy, também acho que é auto-explicativo o que ele faz, caso você tenha mais tarefas para serem executadas quando você der um novo deploy simplesmente coloque ela nesse arquivo usando o env -i na frente como os demais.

Como a gem Trabalha.

A forma como a gem trabalha é bem simples, o que ela faz é usar um pouco do poder do git ao seu favor, basicamente é:

→ Se projeto não estiver versionado então inicio um repositório git localmente e faça o primeiro commit.
→ Adiciona a url remota configurada no config.yml ao git
→ Faz um git push
→ Faz um clone dentro do servidor da pasta repos para rails_app
→ Adiciona a url “remota” dentro do servidor
→ Cria o link simbólico entre public_html e rails_app
→ Cria diretório tmp na aplicação caso não existir
→ Faz upload do arquivo de hook configurado anteriormente
→ Roda Migrations e Restart Servidor

Isso é o que acontece quando você executa gploy -s. Nesse momento seu projeto esta no ar, se tudo aconteceu como o esperado.

Novos Deploys.

Toda vez que você quiser atualizar seu projeto em produção simplesmente faça gpoy -d, ele irá ir até a branch master e fazer um simples push.

Quando usar essa gem?

Eu não recomendaria usar ela para algum projeto real no qual você possa perder dinheiro se o mesmo não estiver ok no ar. Mas acredito que se você esta desenvolvendo algo mais simples e quiser simplesmente colocar em produção para testes externos, ou até mesmo para colocar em produção sistemas ou Web Sites mais simples e que não precisem ficar 24/7 online acredito que possa vir a ser útil, eu até mesmo uso em algumas coisas que estão online.

Logs

O gploy mantem arquivo de log bem simples, ele simplesmente informa qual comando foi executado e se o mesmo foi feito localmente ou remotamente, você pode encontrar esse arquivo dentro da pasta logs do seu projeto Rails.

Testes

Essa gem não tem cobertura 100% de testes unitários, basicamente o que mantenho até o momento são 22 testes usando Rspec. Obviamente não esta tudo testado com esse numero, mas por hora já me ajuda a não ter muita dor de cabeça na hora de mexer no código do projeto. Abaixo o resultado gerado pelo Rcov para a cobertura de testes dessa gem.

Funcionalidades Futuras.

Ainda não tenho nada certo para novas funcionalidades do gploy, o que pretendo implementar é um forma de poder deixar para o usuário escolher qual pasta quer usar para repositório(ou seja, se quiser mudar o nome de repos para qualquer outro), também uma forma simples de usar seu repositório do github, já que o mesmo suporta hooks.

Conclusão

Esta é uma RubyGem simples mas que pode ser útil em certas situações, caso você tenha gostado, faça um fork do projeto no github e sugira modificações e correções de bugs. E quem tiver acesso a outros servidores que não sejam da locaweb por favor entre em contato para que possamos realizar alguns testes, mas penso que a estrutura seja a mesma praticamente.

Links:
Source Code: http://github.com/edipofederle/gploy/
RubyGems: http://rubygems.org/gems/gploy

Git Documentation: http://git-scm.com/documentation

Pensamentos Sobre UML e desenvolvimento de Software

Posted in Opinião, Programação, UML on June 28th, 2010 by Edipo L Federle – 1 Comment

Motivação

Bom, normalmente eu não escrevo posts no estilo que esse irá(está) ser escrito, minha motivação para escrever tal texto já vem se criando à um certo tempo, mas agora finalmente resolvi escrever mesmo que o que venho à apresentar seja totalmente bobagem para muitos, mas tenho certeza que será correto ou resoavelmente bom para muitos.

Grande parte da motivação para eu escrever esse texto vem de vários lugares, como por exemplo: universidade,…. bom basicamente a universidade encapsula todo o resto, o que inclue professores, alunos e outras n váriaveis. ( ou seriam constantes??)

Bom dito isso vamos começar.

Nota I

Quero deixar bem claro aqui que não sou um conhecedor profundo de NADA, muito menos dos tópicos desse posts. Tudo que for apresentando aqui se refere basiscamente ao que eu penso e idéias das quais simpatizo.

Entregue-me um diagrama e lhe entregarei um Software

A grande maioria das universidade(ou não) ensinam UML, não vamos entrar em questões se isso é bom ou ruim, o fato é que UML não é tudo, você não consegue fazer um software apenas com um(s) diagrama(s) UML, e certamente você não não irá fazer um software seguindo fielmente uma especificação de diagrama de classe por exemplo, é basicamente sobre isso que esse post irá tratar…..

Diagramas, Diagramas, Diagramas

Sejamos sincero com nos mesmo, somente UML não é suficiente, o que muitos pregam por ai parecendo xiitas é que a única coisa que você precisa para fazer um software é uma especificação vinda de algum analista de sistema ou sei la quem vestindo um terno.  Não estou falando aqui que a UML não é boa ou que não resolve alguns problemas, de forma alguma, acho a UML um ótima ferramenta para expor visualmente algumas idéias e fluxos mais complexos de um sistemas,  mas onde eu acredito que realmente reside o bom uso de UML é na comunicação, ou seja fazer realmente o que seja importante, não sair desenhando todas as classes do sistema e em cada classe todos atribuitos e métodos, isso é simplesmente perda de tempo, acredito que o bom uso da UML seja pra coisas realmente importante, algo como “para se ter uma ideia”. Você quer detalhamento? Qual melhor local para isso do que no código?, é nesse que você tem que ser detalhado, cuidadoso e muito especifico, pois é isso que irá fazer seu software funcionar ou não.

Agora vamos ser realistas, na grande parte das vezes os Softwares não passam de um monte de cadastros(CRUDs e mais CRUDs) e não me entra na cabeça fazer meia dúzia de diagramas para fazer especificações sobre como implementar um simples CRUD que em 90% dos casos não tem nada de especial e nem vou entrar no assunto de documentações de casos de uso, ah ia me esquecendo casos de uso de ….. CRUD.

Acredito que grande parte disso tudo venha do modelo de desenvolvimentos tradicional de software o cascata, onde existem níveis bem definidos e funções bem especificadas em cada nível, ou seja:

Finalizada um etapa podemos seguir para a próxima, basicamente aquela história, “toma aí o diagrama peão(programador) codifica essa especificação assim como um pedreiro segue uma planta de um engenheiro, no final você vai ter um software “. Usei a palavra peão para programador pois é assim que se parece, e é assim que muitos pensam. Essa abordagem me sugere dois principal resultados, um, o projeto de software é concluído fora do prazo, do orçamento e em grande parte das funcionalidades não batem com o que o cliente solicitou, o sistema vai para produção e a empresa fica eternamente pagando manutenções para que sejam corrigidos problemas que  deviam ter sido detectados na face de analise ainda( e que passaram despercebidos pelos testes), problemas esses muitas vezes de mal entendimento de requesitos do cliente; segunda, o software não é finalizado.

Então a UML não serve ?

Sou suspeito para falar isso, sou um fã de metodologias agéis, como eXtreme Programming por exemplo, eu realmente nunca ouvi falar de uma equipe XP usar diagramas de UML para nada, e segundo a literatura existente isso é pouco feito, segue um trecho do artigo “O Design Está Morto?” de Martin Fowler, que recomendo a todos ler.

“Há diversos pontos de incompatibilidade. É fato que XP possui muito pouca ênfase em diagramas. Embora a posição oficial é a de “usá-los quando eles forem úteis”, há uma mensagem implícita que diz que “verdadeiros adeptos de XP não fazem diagramas”. Esta conclusão é reforçada pelo fato de que pessoas como Kent não se sentem confortáveis com diagramas; na verdade eu nunca vi Kent voluntariamente desenhar um diagrama de software em uma notação determinada.”

E nem é pelo fato de não se usar de diagramas que não teremos um bom software, existe outras n técnicas para tal função que acredito ser muito mais interessante e mais proxima do cliente também, como os cartões CRC:

Acho isso muito elegante e eficiente, recomendo ler http://www.agilemodeling.com/artifacts/crcModel.htm que foi de onde tirei essas duas imagens acima.

Não estou falando aqui que deve-se substituir UML por cartões CRC, o que eu falo é que existe algumas situações onde cada um tem seu maior valor e praticidade, ou um junção de ambos como o Martin Fowler diz que usa, na realidade o que o que realmente importa é saber medir as coisas e saber usar a coisa mais adequada em cada situação e não tentar forçar o uso de uma única ferramenta para resolver todos os problemas e esperar grandes resultados.

O que realmente queria dizer nesse post todo é que muitas vezes principalmente em universidade e certos professores acabam achando que aquilo que é passado na aula é tudo o que se tem para resolver problemas, e só aquilo que deve ser usado e pronto, me de ótimos resultados com isso, quando as coisas são muito mais complicadas… ou posso simplesmente esta falando bobagem….. quem sabe.


Minha Primeira RubyGem – Gploy: automatizando deployment rails usando git push

Posted in Programação, Ruby/Rails on March 31st, 2010 by Edipo L Federle – 1 Comment

Olá pessoas, ja fazia um tempão que não postava nada aqui, mas a coisa anda corrida por esses lados, mas vamos ao post.

Recetemente lancei para o público a primeira gem que me arrisquei a fazer, essa gem está longe de ser perfeita e também esta bem longe de ter um bom código, mas como é a primeira me perdoem :D .

O que essa gem faz é simplesmente configurar seu projeto rails para usar o git para automatizar seu deploys, essa gem usas as configurações citadas pelo Fábio Akita neste post, ou seja configura seu projeto localmente e o seu servidor para isso. Como sstou com um pouco de preguiça :D irei colocar aqui somente por enquanto o link para o github e la tem a documentação(em inglês) de como usar(é fácil).

Github Projet Page

RubyGem Page

Valeu pessoas e comentem.

Ruby Série #6 – Exceções e Manipulação de Exceções – Parte 1

Posted in Programação, Ruby/Rails on February 16th, 2010 by Edipo L Federle – Be the first to comment

Warning: Missing argument 1 for GeSHi::GeSHi(), called in /home/storage/f/73/ab/bitside1/public_html/edipo_blog/blog/wp-content/plugins/codecolorer/codecolorer-core.php on line 137 and defined in /home/storage/f/73/ab/bitside1/public_html/edipo_blog/blog/wp-content/plugins/deans_code_highlighter/geshi.php on line 432

Warning: Missing argument 2 for GeSHi::GeSHi(), called in /home/storage/f/73/ab/bitside1/public_html/edipo_blog/blog/wp-content/plugins/codecolorer/codecolorer-core.php on line 137 and defined in /home/storage/f/73/ab/bitside1/public_html/edipo_blog/blog/wp-content/plugins/deans_code_highlighter/geshi.php on line 432

Em linhas gerais uma exceção é um objeto que indica um tipo de condição excepcional, ela indica que algo muito errado aconteceu, um clássico exemplo de exceção é a divisão por zero, aposto que todos já passaram por algum caso de divisão por zero, chamar métodos que não existem, passar argumentos errados para métodos e assim por diante, esses exemplos citados são todos erros de programação, mas uma exceção não é somente levantada por conta disso, também podemos ter outros tipos de exceções como tentar fazer o uso da rede quando a mesama estiver off.

Não irei falar mais sobre o que são exceções mas recomendo fortemente a leitura na wikipedia sobre isso.

Quando algum erro acontece, por exemplo à passagem de um argumento inválido para um método qualquer dizemos que uma exceção é levantada, por padrão o Ruby finaliza o programa quando algo do tipo acontece, mas como iremos ver é possível fazer à declaração de manipuladores de exceções, isto é um bloco de código que é sempre executado se uma exceção acontecer na execução de um bloco de código, quando uma exceção é levantada o que acontece é a transferência do fluxo de controle para um código que irá tratar essa exceção. Possivelmente você pode tentar fazer uma comparação com a delaração break para sair de um laço por exemplo, mas como iremos ver mais adiante as exceções são bem diferentes, poderosas e flexíveis ao ponto de nos premitir transmitir o fluxo para n blocos.

No Ruby podemos fazer o uso do método raise para levantar exceções e fazer o uso da cláusula rescue para tratar as exceções.
Todas exceções que são levantadas por raise são uma instância de classe Exception ou de alguma de suas subclasses.

Segue abaixo a hierarquia da classe Exception:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Exception
 NoMemoryError
 ScriptError
   LoadError
   NotImplementedError
   SyntaxError
 SignalException
   Interrupt
 StandardError
   ArgumentError
   IOError
     EOFError
   IndexError
   LocalJumpError
   NameError
     NoMethodError
   RangeError
     FloatDomainError
   RegexpError
   RuntimeError
   SecurityError
   SystemCallError
   SystemStackError
   ThreadError
   TypeError
   ZeroDivisionError
 SystemExit
 fatal

Logicamente voçê não tem que saber cada uma delas(seus nomes não bem óbvios) o que você deve ter em mente é que algumas dessas classes extendem uma classe conhecida como StandardError, ou seja, exceções, digamos assim que acontecem com mais frequência, algumas outra expressões representam níveis bem mais baixos, coisas que com menos possibilidade de recuperação logo os programas Ruby(normalmente) não tentam fazer a sua manipulação.

Objetos dos métodos de excecção.

Temos dois métodos que podem retornar alguns detalhes sobre uma dada exeção, esses métos são da classe Exception, message irá retornar uma sequência que permite obter alguns detalhes que podem ser entendidos por seres humanos, facilitando o entendimento de erros.
Também temos outro método bastante importante que é o backtrace, backtrace irá retornar um array de sequências representando uma pilha no ponto em que a exceção foi levantada.

A[0] = posição no qual a exceção foi levantada.
A[1] = posição no qual o método que levantou a exceção foi chamado.
A[2] = posição no qual esse método foi chmado.

E por ai vai, para poder ver um rastreamento da pilha o Ruby fornece um Método Kernel caller.

Objetos de Exceção.

Objetos de exceção são criados pelo método raise, também temos a opção de fazer a criação de nossos próprios objetos, normalmente usando o new ou com outra classe de métodos exception.

Lançando Exceções com Raise.

Quando um método do Kernel é sobreescreito uma exceção é levantada, fail é usado certas vezes quando há certa expectativa que seu programa deva ser finalizado pela exceção.
Existem n formas de se invocar o método raise, veremos abaixo algumas dessas formas:

Raise sem Argumentos

Se o método raise for chamado sem nenhum argumento, o mesmo irá criar um objeto do tipo RunTimeError que não irá ter nenhuma mensagem e então o levanta, por hora se raise for usado também sem argumento mas dentro de um rescue(iremos ver logo ele) o que irá acontencer é que a exceção(que estava sem manipulada) irá ser re-levantada.

Raise com um único argumento

Caso o raise for chamdo com um único argumento (objeto exception) ele irá levantar essa exceção.( Não é um forma muito comun se fazer o uso do raise)

Raise com uma sequencia de argumentos.

Neste caso será criado um objeto novo de exceção( RunTimeError), é uma forma comun de fazer o uso do raise.

Raise com objeto que possua uma exceção

Neste caso raise invoca tal método e levanta o objeto Exception que o mesmo retona.
OBS: A classe Exception possue um método exception, isso quer dizer que você pode especificar a classe do objeto para qualquer tipo de exceçao para ser o primeiro argumento do raise.

Raise com sequencia no terceiro argumento

Neste caso um array de sequências é especificado e então serão usados como o backtrace do objeto(exceção).
OBS: Caso este terceiro argumentos não esteja especificado raise ira usar Kernel caller no backtrace.

Exemplo 1:

Até agora falamos muito, mas não colocamos nada em código ainda, vamos fazer um exemplo bem simples para começar, meio batido mas vou usar o exemplo fatorial novamente.

1
2
3
4
5
6
7
8
9
10
def fatorial(n)
  raise "Argumento invalido" if n < 1
  return 1 if n == 1
  n * fatorial(n-1)
end

puts fatorial(5)
puts fatorial(4)
puts fatorial(10)
puts fatorial(-4)

ruby ex.rb
120
24
3628800
ex.rb:2:in `fatorial’: Argumento invalido (RuntimeError)
from ex.rb:10

Este caso se encaixa no tipo de uso do raise um um único argumento, como dito antes temos outras formas de fazer a mesma coisa, por exemplo:

raise “Argumento invalido” if n < 1
pode ser perfeitamente substituido por:
raise RuntimeError "Argumento invalido" if n < 1
raise RuntimeError.new "Argumento invalido" if n < 1 ou
raise RuntimeError.exception "Argumento invalido" if n < 1

Claramente uma exceção RuntimeError não parece o mais apropriada para o caso do fatorial acima seria mais adequado usar um ArgumentError, ficando assim:

1
2
3
4
5
6
7
8
9
10
def fatorial(n)
  raise ArgumentError if n < 1
  return 1 if n == 1
  n * fatorial(n-1)
end

puts fatorial(5)
puts fatorial(4)
puts fatorial(10)
puts fatorial(-4)

ruby ex.rb
120
24
3628800
ex.rb:2:in `fatorial’: ArgumentError (ArgumentError)
from ex.rb:10

ou até mesmo você pode personalizar um pouco essa mensagem, por exemplo fazendo o seguinte:

1
2
3
4
5
6
7
def fatorial(n)
  raise ArgumentError, "Esperava um argumento >= 1. Mas retornou #{n}", caller if n < 1
  return 1 if n == 1
  n * fatorial(n-1)
end

puts fatorial(-4)

ruby ex.rb
ex.rb:7: Esperava um argumento >= 1. Mas retornou -4 (ArgumentError)

Bom, bem melhor a mensagem assim ? O exemplo do fatorial é um código simples, você não irá querer escrever testes unitários para ele(devia), pois podemos pensar facilmente nos casos em que ele irá falhar, se o código fose algo mais complexo e com n casos seria muito útil termos testes para eles, mas será que esse código de fatorial está ok ? claramente vemos que ele simplesmente checa se o número é positivo, mas não chega o tipo, isso pode ser facilmente resolvido adicionando um outro raise, assim:

1
2
3
4
5
6
def fatorial(n)
  raise TypeError, "Valor invalido, somente inteiros positivos" unless n.is_a? Integer
  raise ArgumentError, "Esperava um argumento >= 1. Mas retornou #{n}", caller if n < 1
  return 1 if n == 1
  n * fatorial(n-1)
end

E por curiosidade aqui vai um simples teste unitário para o código acima:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
require "test/unit"
require "fatorial.rb"

class TestLibraryFileName < Test::Unit::TestCase
  def test_simples_cases
    assert_equal(120, fatorial(5))
    assert_equal(6, fatorial(3))
  end
 
  def test_negative_numbers
    assert_raise(ArgumentError) {fatorial(-1)}
  end
 
  def test_invalid_argument_type
    assert_raise(TypeError) {fatorial("a")}
  end

end

Uma coisa que deve ser entendida aqui, é que muitas vezes exceçõe irão acontecer mesmo sem agente levanta-lás, ou seja, exceções no próprio código Ruby, então uma lição importante é saber manipula-lás mesmo sem agente nunca lenvantar sequer uma delas.

O manipulador de Execções rescue

O rescue é um declaração que deve ser usada em conjunto com a declaração begin, begin é um delimitador de bloco de código dentro das exceções sendo manipuladas(Vimos um pouco disso no post anterior), a declaração begin parece bom isso:

1
2
3
4
5
begin
  #algum código
rescue Exception => e
  #código da manipualação da exceção vem aqui, qualquer exceção levantada pelo código acima, cai aqui.
end

OBS: o Exception => e é opcional, mas logo vermos que ele é útil.e

Dando um nome para um Objeto de Exceção

Podemos usar váriaveis para atribui-las um objeto de exceção(Exception), por exemplo:

1
2
3
4
5
6
7
8
9
def simple(n)
  raise ArgumentError, "Argumento Invalido" if n < 0
end

begin
  simple(-4)
rescue Exception => e
  puts "#{e.class}: #{e.message}"
end

=>ArgumentError: Argumento Invalido

Agora temos um váriavel global que faz referência ao objecto de exceção ( Exception ), essa váriavel é a $!, temos outras n variáveis globais, outra interessante é a $@ que retorna o local do último erro.

Uma coisa a ser notada aqui é que a váriavel e ficará disponível após o rescue ser finalizado, veja esse exemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
def simple(n)
  raise ArgumentError, "Argumento Invalido" if n < 0
end

begin
  simple(-4)
rescue Exception => e
  puts "Dentro do Rescue"
  puts "#{e.class}: #{e.message}"
  puts $!
  puts "Erro em #{$@}"
end

puts ""
puts "Fora do Rescue"
puts $!
puts e

Exceções por Tipo

As execções mostras acima com o uso do rescue trata exceções StandardError, ou suas subclasses, outras exceções que não tiverem dentro dessa hierarquia sera ignorado, então como podem tratar qualquer tipo de exceções ? Simples, faça o seguinte:

Resuce Exception

Agora você deve saber que para manipular um ArgumentError e atribuir isso para e, é simples:

Rescue ArgumentError => ex

E para definir mais que um tipo? Simples, simplesmente separe por virgula(,) elas.
Então vemos um exemplo de como tratar duas exceções, ArgumentError, e TypeError, mas queremos tratas ambas de forma diferentes.

1
2
3
4
5
6
7
begin
  x = fatorial("f")
rescue ArgumentError => e
  puts "Numero >= que 1 eh preciso"
rescue TypeError => e
  puts "Tente com intiero"
end

Bom pessoal essa foi a primeira parte sobre como tratar exceções no Ruby, na segunda parte iremos ver sobre propagação de exceções, exceções que ocorrem dentro de exceções e outras coisas mais.

Espero que tenham gostado e comentem :D