Olá, tenho o seguinte método que é usado para uma função de autocomplete em JSF. O objetivo dele é receber um valor que pode ser o codigo ou o nome da pessoa e efetuar a busca no banco de dados, caso o valor recebido seja o codigo ele faz a conversão para Integer. Minha dúvida é: posso usar o catch vazio dessa forma? Há como melhorar isso?
Obs: Ele funciona perfeitamente, só quero saber se tem formas mais adequadas de fazer.
public List<PessoaVO> autoCompletePessoa(String value) {
PessoaRN pessoaRN = new PessoaRN();
Integer codPessoa = 0;
try {
codPessoa = Integer.parseInt(value);
value = "";
} catch (NumberFormatException e) {}
return pessoaRN.listarPessoas(codPessoa, value);
}
Grato
/*
- What will happen if you enter another type such as a double, Object Float etc
- This program creates a Person Object
- The only two valid types are Strings and Integers
- Depending on the Type it then sets the corresponding value of the Person object
-
- One could make use of the Builder or Factory patterns to do this, but
- I make use of two Wrapper Objects tone that wraps the String and the other that wraps the Integer
- I had this implement interface ValidField.
- The Person object just has a Valid field as a constructor parameter, thus restricting
- the parameter to an Integer or a String
-
- O que acontecerá se você inserir outro tipo, como duplo, objeto flutuante, etc.
- Este programa cria um objeto Person
- Os únicos dois tipos válidos são Strings e Inteiros
- Dependendo do tipo, ele então define o valor correspondente do objeto Pessoa
-
- Pode-se usar os padrões Builder ou Factory para fazer isso, mas
- Eu utilizo dois tons de Wrapper Objects que envolvem a String e o outro que envolve o Integer
- Fiz com que implementassem a interface ValidField.
- O objeto Person tem apenas um campo Valid como parâmetro do construtor, restringindo assim
- o parâmetro para um inteiro ou uma string
-
*/
public class Main {
public static void main(String... args) {
ValidField value1 = new StringValue("Joao");
ValidField value2= new IntegerValue(123);
// ValidField value3= new Double(123.50); // does not compile
Person p1 = new Person(value1);
Person p2 = new Person(value2);
System.out.println(p1);
System.out.println(p2);
}
}
class Person {
ValidField field;
String name = "";
Integer code = 0;
Person(ValidField field){
this.field = field;
if(field == null)
throw new IllegalArgumentException("Must have a value");
if(field.getValue() instanceof String)
this.name = (String) field.getValue();
else
this.code = (Integer) field.getValue();
}
@Override
public String toString() {
return "Person [name=" + name + ", code=" + code + "]";
}
}
// follwing interface and classes only will allow String and Integers
interface ValidField {
Object getValue();
}
class StringValue implements ValidField{
String value ;
StringValue(String value){
this.value = value;
}
@Override
public String getValue() {
return value;
}
}
class IntegerValue implements ValidField{
Integer value;
IntegerValue(Integer value){
this.value = value;
}
@Override
public Integer getValue() {
return value;
}
}
Vou tentar adaptar para o meu caso, também vou estudar um pouco sobre design patterns, valeu
Também gostaria de saber a opinião das outras pessoas.
Particularmente, no seu caso, não vejo problema em deixar o catch vazio.
Vc poderia colocar só um printlnzinho ali nele só pra saber que caiu ali como um favor pra vc mesmo no futuro.
É que hoje vc sabe claramente que:
- Se for um número, vai retornar pessoas com aquele código,
- Se não, vai retornar pessoas com aquele nome
Mas um dia vc pode se confundir com os dados e se perder nos resultados.
Outra sugestão é separar a funcionalidade do método listarPessoas() em dois:
listarPessoasPorNome()listarPessoasPorCodigo()
Assim:
public List<PessoaVO> autoCompletePessoa(String value) {
PessoaRN pessoaRN = new PessoaRN();
try {
return pessoaRN.listarPessoasPorCodigo(Integer.parseInt(value));
} catch (NumberFormatException e) {
return pessoaRN.listarPessoasPorNome(value);
}
}
é uma opção para não deixar o catch vazio, eu tinha feito algo parecido no inicio, mas achei que estava repetido e desnecessário, dai removi. Vou ter que verificar como fica a performance da busca, já que a base é imensa e a busca é feita de acordo com os caracteres inseridos
1 curtida
Você poderia testar com uma expressão regular se o valor recebido é numérico ou não, se for, você trata como código, senão, trata como nome.
Existem várias diretrizes para quando devemos usar exceções, e acredito que usar uma exceção para validar o tipo de entrada não é uma delas.
No livro “Effective Java” de Joshua Blosh, ele menciona esses, entre outros.
Use exceções apenas para condições excepcionais. Exemplo: não use uma exceção para encerrar uma matriz, entrada do usuário etc.
Embora eu veja que os designers de Java violam isso. por exemplo. EOFException em um ObjectInputStream para idicar o final dos dados
Use exceções capturadas para condições recuperáveis
Use exceções verificadas para condições recuperáveis e exceções de tempo de execução para erros de programação
Não ignore as exceções
Então, no final, se você está escrevendo o programa e sabe o que ele faz e ninguém mais precisa trabalhar nele, então está tudo bem, pois ele funciona.
Mas, no mundo do trabalho, a manutenção pode se tornar um problema.
PS documenta as intenções de forma clara.
Observe que este é apenas o meu ponto de vista e com o que aprendi ao longo da minha jornada, e de forma alguma a maneira perfeita, como todos sabemos, a programação também é uma arte.