Hoje é um bom dia pra aprender a ler mensagens de erro
Esse monte de linhas começando com “at …” formam o stacktrace, que nada mais é do que a pilha de chamadas do seu programa. Basicamente, se eu chamo um método da classe A, que por sua vez chama outro método da classe B, que por sua vez chama outro método da classe C e dá um erro nessa classe, o stacktrace mostrará esta pilha (“deu erro em C, que foi chamado por B, que foi chamado por A”).
No seu caso temos:
Exception in thread “main” java.lang.RuntimeException: Erro na conex�o com o banco de dados
at util.ConnectionFactory.getConnection(ConnectionFactory.java:35)
at controller.ProjectController.save(ProjectController.java:46)
at TodoApp.Main.main(Main.java:25)
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
A primeira linha é o erro propriamente dito: ocorreu algum erro ao se conectar com o banco.
No caso, o erro ocorreu na classe util.ConnectionFactory
, método getConnection
, na linha 35. Este método foi chamado na classe controller.ProjectController
, método save
(linha 46). E este, por sua vez, foi chamado na classe TodoApp.Main
, no método main
(linha 25).
Por fim, o “Caused by” é a causa raiz que gerou o erro. Se não sabe o que ele significa, uma dica básica é pesquisar sobre a mensagem exata. Por exemplo, indo no Google e pesquisando por “com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure”, o primeiro resultado que aparece é esse, que já dá várias dicas sobre o que pode ter causado o problema.
Basicamente, se foi um erro de comunicação (CommunicationsException
, “Communications link failure”), então ocorreu algum problema ao se conectar com o banco de dados (faz sentido, o erro ocorreu em getConnnection
, ou seja, na hora de obter uma conexão). E podem ser vários motivos: o banco de dados não está rodando, alguma configuração (IP, porta, usuário, senha) está errada, etc. Tentou se conectar no banco usando alguma ferramenta externa? Conferiu as configurações? Vá fazendo testes isolados e por eliminação vc vai chegando na causa.
Uma vez que vc aprende a ler as mensagens de erro e isolar os pontos em que ela ocorre, elimina a necessidade de “rever todas as classes novamente”. Vc pesquisa sobre o erro, vê no stacktrace as classes e linhas onde ocorre e foca somente naqueles pontos específicos. Aprenda a debugar, é uma das atividades que toma mais tempo na nossa área, e também uma das mais essenciais.
Outro detalhe importante: apesar de ter várias classes no stacktrace, não quer dizer necessariamente que todas estão dando problema. Isso é apenas a pilha de chamadas, o caminho que o código fez pra chegar no ponto em que deu erro. Claro que às vezes o problema pode estar na classe que iniciou o processo (passou um dado errado pra segunda, que por isso gerou um resultado incorreto que dá erro na terceira), mas tem vezes em que o problema está somente na última (como é o caso aqui). O stacktrace serve pra vc saber exatamente por onde o código passou, e te ajudar a debugar. Mas nem sempre vc precisa revisitar todas as classes.