[quote=Mauricio Linhares][quote=sergiotaborda]Os termos “função” e “procedimento” implicam que ha uma distinção intrínseca ao suporte a cada um por parte da linguagem. método significa que é um membro de uma classe.
Método pode ser chamado de função ou procedimento embora isso não seja correto já que o método SEMPRE retorna algo, mesmo que esse algo seja “nada”. Portanto, eles teriam que ser considerados sempre funções, pelo que a dicotomia função-procedimento perderia o sentido. Dito de outra forma, Função e Procedimento são especialidades de Rotina, mas Método não é uma Rotina, logo não pode ser uma função ou procedimento. [/quote]
Companheiro, considerando que “nada” em Java é null, métodos nem sempre retornam um valor, é só marcar ele como void.
[/quote]
Considerando que “nada” em Java é void, métodos sempre retornam um valor. Mesmo quando retornam void.
O método retorna void , mas void não é um tipo em Java, logo nenhuma variável o pode “conter”.
Logo o codigo acima não faz sentido.
Não faz sentido não porque o método não retorne , mas porque a variável não consegue capturar o que ele retorna.
Para um exemplo do que seria não retornar veja os construtores. Eles nunca retornam valor algum. Nem sequer void.
[quote=Paulo Silveira][quote=sergiotaborda]
Construtores são conjuntos de instruções executados pela JVM antes do objeto ser criado. Construtores não são métodos.
[/quote]
No fundo eles são executados logo depois do objeto ser criado, correto? Tanto que da pra fazer aquela bagunca de guardar uma referencia pro objeto mesmo o construtor lancando exception.[/quote]
Se Objeto fosse a mesma coisa que Referencia vc teria razão. Mas como Objeto não é a referencia que o aponta então não.
Embora no construtor vc tenha acesso a this ( a referencia para o próprio objeto) isso não significa que o objeto já existe.
Repare que se o objeto pode existir sem o construtor o construtor não serve para nada. Bastaria ter um método do tipo “onJVMLoad()” que poderiamos sobreescrever e pronto. Ha!, mas ai eu poderia chamar esse método mesmo quando não estou dentro do processo de construção … danou…
O Objeto só é “oficialmente” construído quando o construtor é executado sem erros.
Experimente acessar um objeto cujo construtor lança uma RuntimeException.
[quote=sergiotaborda]O método retorna void , mas void não é um tipo em Java, logo nenhuma variável o pode “conter”.
Logo o codigo acima não faz sentido.
Não faz sentido não porque o método não retorne , mas porque a variável não consegue capturar o que ele retorna.[/quote]
E desde o Java 5 qualquer coisa pode ser colocada em um Object (até os primitivos são promovidos a Object via boxing), então, se “void” fosse um valor, ele caberia em Object.
[quote=sergiotaborda]Se Objeto fosse a mesma coisa que Referencia vc teria razão. Mas como Objeto não é a referencia que o aponta então não.
Embora no construtor vc tenha acesso a this ( a referencia para o próprio objeto) isso não significa que o objeto já existe.
Repare que se o objeto pode existir sem o construtor o construtor não serve para nada. Bastaria ter um método do tipo “onJVMLoad()” que poderiamos sobreescrever e pronto. Ha!, mas ai eu poderia chamar esse método mesmo quando não estou dentro do processo de construção … danou…
O Objeto só é “oficialmente” construído quando o construtor é executado sem erros.
Experimente acessar um objeto cujo construtor lança uma RuntimeException. [/quote]
Rode isso:
[code=java]public class ExceptionTest {
private static List<ExceptionTest> instances = new ArrayList<ExceptionTest>();
public ExceptionTest() {
instances.add(this);
throw new RuntimeException("Erro!");
}
public static void main(String[] args) {
try { new ExceptionTest(); } catch ( Throwable e ) {}
System.out.println( instances.get(0) );
}
}[/code]
E aqui está um objeto que tem o construtor lançando uma exceção e que mesmo assim tem a sua referência livre na JVM, que era exatamente o que o Paulo havia falado, a referência a “this” pode sim vazar do construtor.
[quote=Mauricio Linhares][quote=sergiotaborda]O método retorna void , mas void não é um tipo em Java, logo nenhuma variável o pode “conter”.
Logo o codigo acima não faz sentido.
Não faz sentido não porque o método não retorne , mas porque a variável não consegue capturar o que ele retorna.[/quote]
E desde o Java 5 qualquer coisa pode ser colocada em um Object (até os primitivos são promovidos a Object via boxing), então, se “void” fosse um valor, ele caberia em Object.[/quote]
Vc não entendeu que a chave da frase é valor ?
O método não retorna um valor porque “void” não é um valor.
O que seria um “valor” ? Algo que possa ser colocado numa variável. QED
A frase citada não diz nada diferente do que eu disse.
Mas o fato dele não retornar um valor, não significa que ele não retorna algo.
Ele retorna algo, exatamente por isso que vc tem que declarar void como retorno !!
Vc não precisaria do void se houvesse um tipo de método que retorna e um que não retorna.
Vc precisa de void porque todos os métodos retornam algo. Só que alguns retornam algo que não é um valor, i.e. algo que pode ser usado pelo programa.
Nada impediria declara um método assim
public fazalgoSemretornar(){
// faz algo
}
Seria um método sem retorno.
A única razão para que vc não possa fazer isso é que: todos os métodos retornam algo.
Recomendo que atente à diferença entre as palavras algo, nada, alguma coisa, void , nulo e valor.
Mas… se um método void não retorna um valor, mas retorna algo, que algo é esse? E, se esse algo de fato não existe, não poderíamos considerar como se o método não retornasse coisa alguma de fato?
Não adianta, você vai terminar discutindo sobre a filosofia do nada e do vazio com ele já que pra ele a inexistência de um valor não é nada e sim alguma coisa
E como a própria expecificação diz, nós usamos “void” apenas para “indicar” que não há valor retornado, ela não diz em momento algum que “void” é retornado, como ele está tentando fazer parecer.
[quote=Mauricio Linhares][quote=sergiotaborda]Se Objeto fosse a mesma coisa que Referencia vc teria razão. Mas como Objeto não é a referencia que o aponta então não.
Embora no construtor vc tenha acesso a this ( a referencia para o próprio objeto) isso não significa que o objeto já existe.
Repare que se o objeto pode existir sem o construtor o construtor não serve para nada. Bastaria ter um método do tipo “onJVMLoad()” que poderiamos sobreescrever e pronto. Ha!, mas ai eu poderia chamar esse método mesmo quando não estou dentro do processo de construção … danou…
O Objeto só é “oficialmente” construído quando o construtor é executado sem erros.
Experimente acessar um objeto cujo construtor lança uma RuntimeException. [/quote]
Rode isso:
[code=java]public class ExceptionTest {
private static List<ExceptionTest> instances = new ArrayList<ExceptionTest>();
public ExceptionTest() {
instances.add(this);
throw new RuntimeException("Erro!");
}
public static void main(String[] args) {
try { new ExceptionTest(); } catch ( Throwable e ) {}
System.out.println( instances.get(0) );
}
}[/code]
E aqui está um objeto que tem o construtor lançando uma exceção e que mesmo assim tem a sua referência livre na JVM, que era exatamente o que o Paulo havia falado, a referência a “this” pode sim vazar do construtor.[/quote]
LoL … isso prova que o objeto instances existe. Não prova que o objeto ExceptionTest existe.
Prova também que é passada ao objeto ExceptionTest uma referencia a ele mesmo e as referencias dos seus atributos. Tudo bem, eu não disse que não passava.
O desafio é pegar a instância que foi criada dentro do try … supondo que alguma foi realmente criada, claro.
Não Sérgio. Execute o código postado uma vez, e você verá que o método toString() do objeto criado é chamado, provando que existe de fato um objeto do tipo ExceptionTest na primeira posição do ArrayList. Comente o código dentro do try/catch e execute o código novamente: ocorrerá um IndexOutOfBoundsException.
Um método sempre retorna. Existe três coisas que ele pode retornar : uma referencia, um primitivo e void. Void é um “terceiro estado”
para o retorno da mesma forma que “null” é um “segundo estado” para referencias. O que é tão difícil de entender aqui ?
Dito isto, um método sempre retorna, mas nem sempre retorna referencia ou primitivo. Quando ele não retorna nenhum destes vc precisa indicar void no tipo de retorno porque esse método não irá retornar um valor. Mas “não irá retornar um valor” é diferente de “não irá retornar”. Deu para entender ?
Se vc me apresentar alguma coisa dizendo que métodos void não retornam, ai beleza. Mas apenas apresentar coisas que dizem que ele não retorna valores, isso não desdiz o que falei. Eu já tinha explicado que void não era um valor. ( e por isso não pode ser colocado em uma variável)
ninguém mencionou “existência” referindo-se ao que o método retorna.
Entendi. Não estava questionando, estava apenas tentando entender. Então, o significado de retornar aqui é “encerrar a execução”, né?
É natural questionar a existência de algo que é retornado pelo método, mesmo que esse algo não seja um valor. Mas agora vi que você falou que o “método retorna”, e não que o “método retorna algo”.
[quote=sergiotaborda]Um método sempre retorna. Existe três coisas que ele pode retornar : uma referencia, um primitivo e void. Void é um “terceiro estado”
para o retorno da mesma forma que “null” é um “segundo estado” para referencias. O que é tão difícil de entender aqui ?[/quote]
“null” não é um “segundo estado” para referências, existe um tipo anônimo null que tem como seu único valor o valor que está na literal “null” do Java:
Outras linguagens, como Ruby, fazem desse objeto “null” um objeto visível na linguagem, que pode ser acessado como qualquer outro objeto (em Ruby ele seria o NilObject).
Acho que aqui você está misturando as bolas. Esse retorno é o retorno de “alguma coisa” ou é o retorno de acabar a execução do método e ele devolver o controle da execução pra quem o chamou?
Ambos são coisas completamente diferentes e toda essa discussão foi iniciada porque “procedures” em linguagens como Pascal não retornam valores mas elas devolvem o fluxo de execução pra quem as chamou, então dizer que um método “retorna” apenas porque ele devolve o fluxo de execução não tem nada haver com o fato do método retornar alguma coisa, já que procedures não retornam anda mas devolvem a execução a quem as chamou.
Eu ficaria realmente muito satisfeito em aceitar a sua teoria se você pudesse citar a parte da JLS que diz que “void” é alguma coisa, mesmo não sendo um valor, porque até agora tudo isso parece apenas a sua opinião pessoal, sem nenhum fundamento na especificação da linguagem. Métodos void devolvem o controle da execução para o método que os chamou quando o seu corpo acaba de executar, mas eles não retornam.
Foi exatamente essa a questão que eu quis levantar. Note que o conceito de retornar no sentido de devolver o controle de execução pra quem o chamou se aplica a construtores também ( que, segundo o Sérgio, não retornam nada porque não é necessário especificar essa condição com a palavra “void” ).
Não Sérgio. Execute o código postado uma vez, e você verá que o método toString() do objeto criado é chamado, provando que existe de fato um objeto do tipo ExceptionTest na primeira posição do ArrayList. Comente o código dentro do try/catch e execute o código novamente: ocorrerá um IndexOutOfBoundsException.[/quote]
Claro que acontecerá, a lista está vazia. Mas a existencia da lista não depende da existencia do objeto ExceptionTest (ela é static ora!)
O fato do toString ser chamado pelo Debugger não prova nada porque o Debugger não faz parte da JVM.
O ponto é: vc consegue obter o objeto criado sim ou não ?
Não ? QED
Sim ? Apresente um código que faça isso.
[quote=sergiotaborda]Claro que acontecerá, a lista está vazia. Mas a existencia da lista não depende da existencia do objeto ExceptionTest (ela é static ora!)
O fato do toString ser chamado pelo Debugger não prova nada porque o Debugger não faz parte da JVM.
O ponto é: vc consegue obter o objeto criado sim ou não ?
Não ? QED
Sim ? Apresente um código que faça isso.[/quote]
Você não entendeu. A lista não está vazia: ela contém uma instância da classe ExceptionTest na posição de índice 0 do ArrayList. Você ao menos executou o código pra verificar? Eu sim.
[EDITADO]
Debugger? De onde você tirou isso?
[/EDITADO]
private static List<ExceptionTest> instances = new ArrayList<ExceptionTest>();
public ExceptionTest() {
instances.add(this);
throw new RuntimeException("Erro!");
}
public static void main(String[] args) {
for ( int x = 0; x < 10; x++ ) {
try { new ExceptionTest(); } catch ( Throwable e ) {}
}
for ( ExceptionTest t : instances ) {
System.out.println(t);
}
}
[quote=Mauricio Linhares][quote=sergiotaborda]Um método sempre retorna. Existe três coisas que ele pode retornar : uma referencia, um primitivo e void. Void é um “terceiro estado”
para o retorno da mesma forma que “null” é um “segundo estado” para referencias. O que é tão difícil de entender aqui ?[/quote]
“null” não é um “segundo estado” para referências, existe um tipo anônimo null que tem como seu único valor o valor que está na literal “null” do Java:
[/quote]
Vc leu esse texto ? Ele fala de “null type” e “null reference”. Null type é um tipo de objeto que é essa que vc se refere como sendo anonimo. Mas eu me referi a null reference. A reference podem seu valor igual a null ou um outro valor. O ponto é: “In practice, the programmer can ignore the null type and just pretend that null is merely a special literal that can be of any reference type.”
Eu posso ignorar que existe um tipo null (ou seja, um objeto cuja referencia é a mesma que o literal null) e aceitar que
null é um “segundo estado” dos tipos de referencia. Eu sei que não existe isso, por isso que coloquei entre aspas. Eu posso aceitar isto, na prática, se eu quiser. É isso que estou fazendo.
Não. Não estou falando do ato de continuar o processo no ponto " seguir " à chamada do método.
Não estou falando daquilo que faz o “return”. Não estou falando de “sair do método”.
[quote]
Eu ficaria realmente muito satisfeito em aceitar a sua teoria se você pudesse citar a parte da JLS que diz que “void” é alguma coisa, mesmo não sendo um valor, porque até agora tudo isso parece apenas a sua opinião pessoal, sem nenhum fundamento na especificação da linguagem. Métodos void devolvem o controle da execução para o método que os chamou quando o seu corpo acaba de executar, mas eles não retornam.[/quote]
Bom, então o seu argumento é: Métodos que declaram void não retornam coisa alguma e os que declara outra coisa é porque retornam algo. Ok. Então OO , em Java tem funções e rotinas. Legal! Agora mostre-me algo na JLS dizendo que Java tem funções e rotinas.
Some do. Some teach. Re rest , look it up.
Se a JLS responde a todas as perguntas, então responda à pergunta do topico com ela. Qual é a diferença em funções e métodos em Java segundo a JLS ?
[quote=tnaires][quote=sergiotaborda]Claro que acontecerá, a lista está vazia. Mas a existencia da lista não depende da existencia do objeto ExceptionTest (ela é static ora!)
O fato do toString ser chamado pelo Debugger não prova nada porque o Debugger não faz parte da JVM.
O ponto é: vc consegue obter o objeto criado sim ou não ?
Não ? QED
Sim ? Apresente um código que faça isso.[/quote]
Você não entendeu. A lista não está vazia: ela contém uma instância da classe ExceptionTest na posição de índice 0 do ArrayList. Você ao menos executou o código pra verificar? Eu sim.
[/quote]
Não , não tinha executado o codigo.
Ok vc consegue obter o objeto. Um erro no construtor não inviabiliza o objecto (!).
