streamalism.org

1. Oversigt

I denne vejledning ser vi på java.lang.NoSuchMethodError og nogle måder at håndtere det på.

2. NoSuchMethodError

Som navnet antyder, det NoSuchMethodError opstår, når en bestemt metode ikke findes. Denne metode kan enten være en instansmetode eller en statisk metode.

I de fleste tilfælde,vi er i stand til at fange denne fejl på kompileringstidspunktet. Derfor, det er ikke et stort problem. Imidlertid, nogle gange kunne det kastes ved kørselstid, så bliver det lidt svært at finde det. I henhold til Oracle-dokumentationen kan denne fejl opstå ved kørsel, hvis en klasse er blevet uforeneligt ændret.

Derfor kan vi støde på denne fejl i følgende tilfælde. For det første, hvis vi bare laver en delvis rekompilering af vores kode. For det andet, hvis der er version uforenelighed med afhængigheder i vores ansøgning, såsom de eksterne krukker.

Bemærk, at NoSuchMethodError arvetræ inkluderer IncompatibleClassChangeError og LinkageError. Disse fejl er forbundet med en inkompatibel klasseændring efter kompilering.

3. Eksempel på NoSuchMethodError

Lad os se denne fejl i aktion med et eksempel. Til dette opretter vi to klasser. Første er Speciel i dag som viser listen over dagens tilbud i en restaurant:

offentlig klasse SpecialToday {privat statisk streng ørken = "Chokoladekage"; offentlig statisk String getDesert () {returner ørken; }}

Anden klasse Hovedmenu kalder metoder fra Tilbud i dag:

public class MainMenu {public static void main (String [] args) {System.out.println ("Dagens tilbud:" + getSpecials ()); } offentlig statisk streng getSpecials () {return SpecialToday.getDesert (); }}

Her vil output være:

Dagens tilbud: Chokoladekage

Dernæst sletter vi metoden getDesert () i Speciel i dag og kompiler kun denne opdaterede klasse igen. Denne gang, når vi kører vores Hovedmenu, vi bemærker følgende runtime-fejl:

Undtagelse i tråden "main" java.lang.NoSuchMethodError: SpecialToday.getDesert () Ljava / lang / String;

4. Sådan håndteres NoSuchMethodError

Lad os nu se, hvordan vi kan håndtere dette. Lad os for ovenstående kode lav en fuldstændig ren kompilering, inklusive begge klasser. Vi bemærker, at fejlen bliver fanget, mens vi kompilerer. Hvis vi bruger en IDE som formørkelse, det vil blive opdaget endnu tidligere, så snart vi opdaterer Tilbud i dag.

Derfor, hvis vi løber ind i denne fejl med vores applikationer, som et første trin, laver vi en fuldstændig ren kompilering. Med maven kører vi mvn ren installation kommando.

Nogle gange er problemet med vores applikations eksterne afhængigheder. I dette tilfælde vil vi først tjek rækkefølgen af ​​krukkerne i byggestien trukket af klassesti-læsseren. Og vi sporer og opdaterer den inkonsekvente krukke.

Men hvis vi stadig støder på denne fejl under kørsel, bliver vi nødt til at grave dybere. Det bliver vi nødt til sørg for, at klasser og krukker Compile-time og Runtime har de samme versioner. Til dette kan vi kør applikationen med -verbose: class option for at kontrollere de indlæste klasser. Vi kan køre kommandoen som følger:

$ java -verbose: klasse com.baeldung.exceptions.nosuchmethoderror.MainMenu [0.014s] [info] [klasse, load] åbnet: / usr / lib / jvm / java-11-openjdk-amd64 / lib / moduler [0.015s ] [info] [klasse, indlæsning] åbnet: /usr/share/java/java-atk-wrapper.jar [0.028s] [info] [klasse, indlæs] java.lang.Objektkilde: fil med delte objekter [0.028s ] [info] [klasse, indlæs] java.io.Serialiserbar kilde: fil med delte objekter

Ved hjælp af denne information om alle klasser, der indlæses i de enkelte krukker, under kørsel, kan vi spore den uforenelige afhængighed.

Vi burde også sørg for, at der ikke er duplikatklasser i to eller flere krukker. I de fleste tilfælde hjælper maven med at kontrollere modstridende afhængigheder direkte. Desuden kan vi køre mvn afhængighed: træ kommando for at få afhængighedstræet for vores projekt som følger:

$ mvn afhængighed: træ [INFO] Scanning efter projekter ... [INFO] [INFO] --------------------------- [INFO] Bygning nosuchmethoderror 0.0.1-SNAPSHOT [INFO] -------------------------------- [jar] ----- ---------------------------- [INFO] [INFO] --- maven-afhængigheds-plugin: 2.8: træ (standard-cli ) @ nosuchmethoderror --- [INFO] com.baeldung.exceptions: nosuchmethoderror: jar: 0.0.1-SNAPSHOT [INFO] \ - org.junit: junit-bom: pom: 5.7.0-M1: kompilere

Vi kan kontrollere bibliotekerne og deres versioner på listen genereret af denne kommando. Desuden kan vi også administrere afhængigheder ved hjælp af maven-tags. Bruger tag, kan vi udelukke den problematiske afhængighed. Bruger tag, kan vi forhindre uønskede afhængigheder i at blive samlet i krukken eller krigen.

5. Konklusion

I denne artikel behandlede vi NoSuchMethodError. Vi diskuterede årsagen til denne fejl og også måder at håndtere den på. For flere detaljer om, hvordan man håndterer fejl korrekt, henvises til vores artikel om fangst af Java-fejl.

Som altid er koden præsenteret i denne artikel tilgængelig på GitHub.