Mas o método sempre lança exceção (estouro de pilha ou a do ponto de saída) e também não tem sentido!
Bem, fora de um contexto isso é stack overflow sem dúvida, afinal o método chama ele mesmo, e o caso base depende de uma variável de instância que ele não modifica. Mas também não consigo pensar em um contexto em que isso esteja correto.
Acho q o Leozin não está considerando o contexto do método. Como ele é executado?
COmo já disseram do jeito que está aí é stackoverflow na certa. A pilha estoura dentro de poucos ciclos já que vai se acumulando. Ah não ser, que haja alguma forma de liberar a pilha internamente, isso não levamos em consideração!
Fazer isso aí em uma classe Java dá pau na certa, mas por ser algo interno da VM pode ser que haja algo que libere a pilha evitando o stackoverflow.
Claro, só estou chutando! 
public static final Long COD_CORRETOR_200000000 = 200000000L,
COD_CORRETOR_299999999 = 299999999L,
COD_CORRETOR_500000000 = 500000000L,
COD_CORRETOR_599999999 = 599999999L;
Como tratar excessões…
Obs: cellModel é um simples pojo tb.
try {
........
} catch (Exception e) {
e.printStackTrace();
cellModel.setCertificateValid(false);
}
try {
cellModel.setCertificateValidationMessage("");
} catch (Exception e) {
cellModel.setCertificateValidationMessage("");
}
try {
cellModel.setCertificateValidationShortMessage("");
} catch (Exception e) {
cellModel.setCertificateValidationShortMessage("");
}
try {
cellModel.setCertificateValidSince(cert.getNotBefore());
} catch (Exception e) {
cellModel.setCertificateValidSince(null);
}
try {
cellModel.setCertificateValidUntil(cert.getNotAfter());
} catch (Exception e) {
cellModel.setCertificateValidUntil(null);
}
try {
cellModel.setLegalPersonName(((X500Name)cert.getSubjectDN()).getCommonName());
} catch (Exception e) {
cellModel.setLegalPersonName("");
}[quote=danieldestro] public static final Long COD_CORRETOR_200000000 = 200000000L,
COD_CORRETOR_299999999 = 299999999L,
COD_CORRETOR_500000000 = 500000000L,
COD_CORRETOR_599999999 = 599999999L;[/quote]
Esse tipo de coisa costuma ocorrer quando é obrigatório usar algum programa como o PMD e/ou o CheckStyle e a regra “não usar números mágicos” está ligada. Como é difícil achar um nome decente para tais constantes, você acaba criando tais constantes com esses nomes malucos.
[quote=Sparcx86]Acho q o Leozin não está considerando o contexto do método. Como ele é executado?
COmo já disseram do jeito que está aí é stackoverflow na certa. A pilha estoura dentro de poucos ciclos já que vai se acumulando. Ah não ser, que haja alguma forma de liberar a pilha internamente, isso não levamos em consideração!
Fazer isso aí em uma classe Java dá pau na certa, mas por ser algo interno da VM pode ser que haja algo que libere a pilha evitando o stackoverflow.
Claro, só estou chutando! [/quote]
O código é claro. O método verifica com um if o atributo setupMode e no else chama a si mesmo.
É certo que o doRename chama a si mesmo porque o método é final e tem a exata mesma assinatura, ou seja, não vai chamar nenhum método sobrescrito.
Não há código nativo. Não é um código de alguma classe que tem tratamento especial na JVM (tal como Class ou Enum). Não há geração dinâmica de bytecodes, reflection ou qualquer outra coisa que possa mudar o significado deste método.
Pode ser que haja um static import para alguma classe que tenha um método estático doRename. Mas mesmo assim, quando o compilador procurar doRename na tabela de símbolos, vai achar o método local.
O único caso onde isso talvez fizesse sentido seria se o atributo setupMode for volatile e ser modificada por outra thread enquanto o método é executado antes que ocorra o StackOverflowError. Mesmo se esse for o objetivo, seria uma forma extremamente podre, mal-feita, ineficiente e gambiarrosa de prover comunicação entre Threads. E o resultado é sempre OU um SchemaViolationException ou um StackOverflowError, portanto, o método nunca faz alguma coisa útil e SEMPRE falha.
Ou seja, este método é extremamente digno de estar neste tópico. :lol:
int Desculpas = 0;
while (Desculpas < 1000) {
System.out.println("Desculpas");
}
Muitas vezes na faculdade, fazemos coisas que devemos nos orgulhar…
Essa não é uma das que eu me orgulho…
UASHAushAUHSAuhsaHUSAuhsa…
Instância da instância da instância da instância… do EJB.
[code]@Stateless(name=“EuSeiProgramar”)
public class EuSeiProgramarBean implements EuSeiProgramar {
@EJB
private EuSeiProgramar seiSim;
public void euFacoAlgoLegal( String valorImportante ) {
// faz algo
// pra que chamar o método do próprio EJB se eu posso chamar
// o método de outro EJB??? Acho que dá maior escalabilidade!
Double valor = seiSim.calculaUmValor( xpto );
// faz mais um pouco
}
public Double calculaUmValor( String algoADeclarar ) {
// não te interessa
return valor;
}
}[/code]
Novo Design Pattern - Enum Business Delegate:
[code]package br.ALGUMA.SUPER.EMPRESA.delegate;
public enum Delegate {
FORNECEDOR(JNDI_NAME_Fornecedor),
CONVENIO(JNDI_NAME_Convenio),
PRODUTO(JNDI_NAME_Produto),
HISTORICO(JNDI_NAME_Historico),
// alguns outros aqui
;
/** caminho session. */
private final String caminhoSession; // FINAL??? COMO ASSIM???
/**
- Instancia um novo delegate.
-
@param caminhoSession caminho session
*/
private Delegate(String caminhoSession) {
this.caminhoSession = caminhoSession;
}
/**
- Gets EJB.
*/
public Object getEJB() {
try {
return ServiceLocator.getInstance().getEJB(caminhoSession);
} catch (Exception e) {
throw new RuntimeException(“falha ao fazer o loockup do ejb”, e);
// loockup é um LOOKUP com hiccup (soluço)???
}
}
}
[/code]
Fácil de usar:
Foobar foo = (FooBar) Delegate.FORNECEDOR.getEJB();Achei que ZERO era um valor constante, descobri que não é!
/** Constantes utilitárias. */
public static final Double VALOR_DOUBLE_ZERO = 0.0;
/** Constante utilitária. */
public static final Long VALOR_LONG_ZERO = 0L;
[quote=mario.fts]quando eu li, não pude deixar de postar aqui…
Olha o que os caras estão fazendo pra pegar o MAX de uma coluna na tabela
int cont = 0;
try{
setSql("SELECT * FROM Est WHERE est=?");
ps = conn.prepareStatement(getSql());
ps.setString(1, getEst());
rs = ps.executeQuery();
while(rs.next()){
if(cont < rs.getInt("colunast"))
cont = rs.getInt("colunast");
}
}
catch(SQLException ex){
ex.printStackTrace();
}aqui: http://www.guj.com.br/posts/list/107335.java[/quote]
Eu já vi ´"peor"
SELECT * FROM (Select * from esquema.tabela Order by nsu desc) Where rownum < 2
e depois ainda era acrescentado mais 1 ao resultado depois via código java
o código acima poderia ser facilmente trocado por
select max(nsu) +1 from esquema.tabelaSELECT MAX é, em geral, onde ocorrem muitos erros num sistema. Programadores inexperientes não se preocuparam (ou não conhecem) com os problemas de concorrência que isso pode ocasionar em muitos casos.
caraaaaaca daniel, esse novo design pattern é muito show de bola hahahaha
[quote=danieldestro]Novo Design Pattern - Enum Business Delegate:
…[/quote]
Bem, de certa forma esse “final” faz sentido. Enums mutáveis são aberrações muito grandes, que aliás ainda não vi neste tópico.
Agora quanto a “brilhante” idéia de usar um enum de delegates com um loockup eu não tenho o que comentar.
if ( DtInicoVigen.after(DtAtualPortal) ) {
if (!DtInicoVigen().equals(DtAtualPortal) ) {
Date dtFimVigencia = DateUtil.calculaNovaData(DtInicoVigen, 0, 0, 1);
DtIniVigenciaMatriz(dtFimVigencia);
} else {
DtIniVigenciaMatriz(DtAtualPortal);
}
} else {
DtIniVigenciaMatriz(DtAtualPortal);
}
Além de errado ( after aninhado com equals ), o correto seria:
if ( DtInicoVigen.before(DtAtualPortal) || DtInicoVigen.equals(DtAtualPortal) ) {
DtIniVigenciaMatriz(DtAtualPortal);
} else {
Date dtFimVigencia = DateUtil.calculaNovaData(DtInicoVigen, 0, 0, 1);
DtIniVigenciaMatriz(dtFimVigencia);
}
Incrível função para validar se uma string é numérica:[code]function validanumero(numero) {
var valid = “0123456789”;
var ok = “yes”;
var temp;
for (var i=0; i< numero.length; i++){
temp = “” + numero.substring(i, i+1);
if (valid.indexOf(temp) == "-1")
ok = "no";
}
if (ok == “no”)
return(false);
return(true);
}[/code]
Reinventando a roda.
O POGramador:
[quote] [code]public int arredondarParaCima(double valor) {
double valorInicial = 0;
double valorFinal = 1;
boolean faca = true;
while (faca == true) {
if (valor >= valorInicial && valor <= valorFinal) {
faca = false;
} else {
valorInicial++;
valorFinal++;
}
}
return (int) valorFinal;
}[/code][/quote]
Eu:
[quote=danieldestro]Reinventando a roda.
O POGramador:
[quote] public int arredondarParaCima(double valor) {
double valorInicial = 0;
double valorFinal = 1;
boolean faca = true;
while (faca == true) {
if (valor >= valorInicial && valor <= valorFinal) {
faca = false;
} else {
valorInicial++;
valorFinal++;
}
}
return (int) valorFinal;
}[/quote]
Eu:
isso só pode ser exercicio academico!!! não tem outra explicação :!:
Não ia postar esta mas depois de ler os post de vcs me decidi; toma esta aqui:
[code]// Sem isso, o for acima faz pular um
// elemento
if (!tbDestino.equals(“TBPESSOA”))
i–;
[/code]
Detalhe, possui várias linhas deste tipo dentro de um statement while com mais de 800 linhas dentro :shock:
Caras…toda vez que vejo o comentario deste código eu fico sem palavras, é muita emoção.
flws