Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
onde é que dá o erro?
- na linha do return -> indica que o return está errado
- no metodo como um todo -> indica um erro no metodo
o que acontece se tipoFuincionario nao for nenhum dos 3 tipos, o que o metodo irá retornar?
o problema nao é o tipo de retorno, mas sim a falta de retorno caso nenhuma das opcoes do switch for válida.
Por isso que o switch (quase) sempre deveria ter um default: (com uma Exception ou eventualmente um return)
[]] _________________ Nome real: Carlos F. Heuberger
Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!
O Eclipse destaca o trecho que compreende o nome do método e parâmetros.
(Maldito Eclipse!) Era a falta do default que ocasionava o problema. Não o coloquei porque tipoFuncionario é uma enumeração. Tal execução ocasionaria em uma Exception (certo?) abortando a execução sumariamente(?)
Mudamos o foco, não há mais problema, mas deu-se 'pano pra manga' pra aprendizado
nao é culpa do eclipse e sim do compilador, que por sua vez segue as regras do java.
Normalmente esse código nao compila -> nao roda -> nao da Exception.
Pode parecer estranho o compilador dar erro no caso de ter todos os valores de uma enum... mas a enum pode ser definida em outro arquivo (ou pacote, ou biblioteca). Dessa maneira é possível compilar o seu código com uma versao do enum e mais tarde adicionar novos valores ao enum e somente compilar o enum (sem alterar e compilar o seu código).
[]]
_________________ Nome real: Carlos F. Heuberger
Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!
Pensando desta maneira faz total sentido. Só fazendo esta verificação através do default para garantir a facilidade na identificação de uma modificação na minha enumeração.
Curiosidade: Isto aconteceria mesmo se o enum fosse declarado como final?
o final nao mudaria nada:
1) mas, nesse "nível", o significado do final é evitar uma subclasse da classe (enum), o que nao impede a mudanca do próprio enum;
2) se o efeito do final fosse evitar a mudanca do enum, nao teria como evitar que alguem mude o source. O Java teria que ter uma "memoria universal" onde armazenar todos os enums uma vez definidos final, e nos, os programadores nunca poderiamos fazer um erro nesses enums...
MAS, o final no enum é um erro de compilacao: o enum é implicitamente final (a nao ser que pelo menos uma das constantes tenha um "corpo") e portanto nao da para fazer um "subenum" ou subclasse de uma enum.
[]] _________________ Nome real: Carlos F. Heuberger
Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!
MarburgPosts:19
Boa tarde a todos,
É vergonhoso o que vem a seguir mas, não consigo fazer uma simples multiplicação em Java!
No Eclipse, temos a seguinte mensagem na assinatura do método:
This method must return a result of type double.
Nem mesmo a utilização de cast explícito funcionou. Originalmente, a intenção era que tudo onde está double fosse do tipo float.
Alguma idéia alguém?
simuPosts:9416
onde é que dá o erro?
- na linha do return -> indica que o return está errado
- no metodo como um todo -> indica um erro no metodo
o que acontece se tipoFuincionario nao for nenhum dos 3 tipos, o que o metodo irá retornar?
o problema nao é o tipo de retorno, mas sim a falta de retorno caso nenhuma das opcoes do switch for válida.
Por isso que o switch (quase) sempre deveria ter um default: (com uma Exception ou eventualmente um return)
[]]
_________________ Nome real: Carlos F. Heuberger
Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!
"The mod javafree deserves, but not the one it needs right now."
--------------------
Não leio nem respondo MPs!
This posting is provided AS IS with no warranties and confers no rights.
MarburgPosts:19
Em primeiro lugar, obrigado pela resposta.
O Eclipse destaca o trecho que compreende o nome do método e parâmetros.
(Maldito Eclipse!) Era a falta do default que ocasionava o problema. Não o coloquei porque tipoFuncionario é uma enumeração. Tal execução ocasionaria em uma Exception (certo?) abortando a execução sumariamente(?)
Mudamos o foco, não há mais problema, mas deu-se 'pano pra manga' pra aprendizado
Obrigado!
simuPosts:9416
nao é culpa do eclipse e sim do compilador, que por sua vez segue as regras do java.
Normalmente esse código nao compila -> nao roda -> nao da Exception.
Pode parecer estranho o compilador dar erro no caso de ter todos os valores de uma enum... mas a enum pode ser definida em outro arquivo (ou pacote, ou biblioteca). Dessa maneira é possível compilar o seu código com uma versao do enum e mais tarde adicionar novos valores ao enum e somente compilar o enum (sem alterar e compilar o seu código).
[]]
_________________ Nome real: Carlos F. Heuberger
Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!
"The mod javafree deserves, but not the one it needs right now."
--------------------
Não leio nem respondo MPs!
This posting is provided AS IS with no warranties and confers no rights.
MarburgPosts:19
Pensando desta maneira faz total sentido. Só fazendo esta verificação através do default para garantir a facilidade na identificação de uma modificação na minha enumeração.
Curiosidade: Isto aconteceria mesmo se o enum fosse declarado como final?
Abraço!
simuPosts:9416
o final nao mudaria nada:
1) mas, nesse "nível", o significado do final é evitar uma subclasse da classe (enum), o que nao impede a mudanca do próprio enum;
2) se o efeito do final fosse evitar a mudanca do enum, nao teria como evitar que alguem mude o source. O Java teria que ter uma "memoria universal" onde armazenar todos os enums uma vez definidos final, e nos, os programadores nunca poderiamos fazer um erro nesses enums...
MAS, o final no enum é um erro de compilacao: o enum é implicitamente final (a nao ser que pelo menos uma das constantes tenha um "corpo") e portanto nao da para fazer um "subenum" ou subclasse de uma enum.
[]]
_________________ Nome real: Carlos F. Heuberger
Removeram os meus direitos de administrador e moderador - sem aviso, pela segunda vez - contate o ombudsman (?), a equipejavafree ou a "alta gerência" se necessário - Que pena... que terminou dessa maneira!
"The mod javafree deserves, but not the one it needs right now."
--------------------
Não leio nem respondo MPs!
This posting is provided AS IS with no warranties and confers no rights.
Relacionados
Java Arquivo jar no linux
http://javafree.uol.com.br/topic-890637-Java-Arquivo-jar-no-linux.html
Ajuda Calcular data
http://javafree.uol.com.br/topic-890632-Ajuda-Calcular-data.html
Ajuda em exercício usando for e printf
http://javafree.uol.com.br/topic-874989-Ajuda-em-exercicio-usando-for-e-printf.html
Problemas em passar parametro para pesquisa
http://javafree.uol.com.br/topic-890624-Problemas-em-passar-parametro-para-pesquisa.html
Erro em cadastro com arraylist irreconhecivel
http://javafree.uol.com.br/topic-890626-Erro-em-cadastro-com-arraylist-irreconhecivel.html