streamalism.org

1. Oversikt

I denne opplæringen vil vi se på java.lang.NoSuchMethodError og noen måter å håndtere det på.

2. NoSuchMethodError

Som navnet antyder, de NoSuchMethodError oppstår når en bestemt metode ikke blir funnet. Denne metoden kan enten være en forekomstmetode eller en statisk metode.

I de fleste tilfeller,vi er i stand til å fange denne feilen på kompileringstidspunktet. Derfor, det er ikke et stort problem. Derimot, noen ganger kan det kastes ved kjøretid, da blir det litt vanskelig å finne det. I følge Oracle-dokumentasjonen kan denne feilen oppstå ved kjøretid hvis en klasse er uforenlig endret.

Derfor kan vi støte på denne feilen i følgende tilfeller. For det første, hvis vi bare gjør en delvis rekompilering av koden vår. For det andre, hvis det er versjonskompatibilitet med avhengighetene i applikasjonen vår, for eksempel de eksterne glassene.

Merk at NoSuchMethodError arvetre inkluderer IncompatibleClassChangeError og LinkageError. Disse feilene er forbundet med en inkompatibel klasseendring etter kompilering.

3. Eksempel på NoSuchMethodError

La oss se denne feilen i aksjon med et eksempel. For dette lager vi to klasser. Første er Spesiell i dag som vil liste opp spesialtilbud for dagen i en restaurant:

offentlig klasse SpecialToday {privat statisk strengørken = "Sjokoladekake"; offentlig statisk streng getDesert () {retur ørken; }}

Andre klasse Hovedmeny kaller metoder fra Spesialer i dag:

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

Her vil utgangen være:

Dagens spesialiteter: Sjokoladekake

Deretter sletter vi metoden getDesert () i Spesiell i dag og kompiler bare denne oppdaterte klassen på nytt. Denne gangen når vi kjører vår Hovedmeny, vi merker følgende kjøretidsfeil:

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

4. Hvordan håndtere NoSuchMethodError

La oss nå se hvordan vi kan takle dette. For koden ovenfor, la oss gjør en fullstendig rengjøring, inkludert begge klassene. Vi vil merke at feilen blir fanget mens vi kompilerer. Hvis vi bruker en IDE som formørkelse, det vil bli oppdaget enda tidligere, så snart vi oppdaterer Spesialer i dag.

Derfor, hvis vi støter på denne feilen med applikasjonene våre, som et første trinn, vil vi gjøre en fullstendig kompilering. Med maven kjører vi mvn ren installasjon kommando.

Noen ganger er problemet med de eksterne avhengighetene av applikasjonen vår. I dette tilfellet vil vi først sjekk rekkefølgen på glassene i byggestien trukket av klassesti-lasteren. Og vi sporer og oppdaterer den inkonsekvente krukken.

Imidlertid, hvis vi fremdeles støter på denne feilen ved kjøretid, må vi grave dypere. Vi må sørg for at kompileringstid og Runtime-klasser og krukker har samme versjoner. For dette kan vi kjør applikasjonen med -verbose: class option for å sjekke de lastede klassene. Vi kan kjøre kommandoen som følger:

$ java -verbose: klasse com.baeldung.exceptions.nosuchmethoderror.MainMenu [0.014s] [info] [class, load] opens: / usr / lib / jvm / java-11-openjdk-amd64 / lib / modules [0.015s ] [info] [klasse, last] åpnet: /usr/share/java/java-atk-wrapper.jar [0.028s] [info] [class, load] java.lang.Object source: shared objects file [0.028s ] [info] [class, load] java.io.Serialiserbar kilde: filen med delte objekter

Ved å bruke denne informasjonen om alle klassene som blir lastet i de enkelte glassene, kan vi spore den uforenlige avhengigheten.

Vi burde også sørg for at det ikke er duplikatklasser i to eller flere krukker. I de fleste tilfeller vil maven bidra til å kontrollere motstridende avhengigheter direkte. Videre kan vi kjøre mvn avhengighet: tre kommando for å få avhengighetstreet til prosjektet vårt som følger:

$ mvn avhengighet: tre [INFO] Skanner etter prosjekter ... [INFO] [INFO] --------------------------- [INFO] Bygning nosuchmethoderror 0.0.1-SNAPSHOT [INFO] -------------------------------- [jar] ----- ---------------------------- [INFO] [INFO] --- maven-avhengighets-plugin: 2.8: tre (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 sjekke bibliotekene og deres versjoner i listen generert av denne kommandoen. Videre kan vi også administrere avhengigheter ved hjelp av maven-koder. Bruker kan vi ekskludere den problematiske avhengigheten. Bruker tag, kan vi forhindre at uønskede avhengigheter blir samlet i krukken eller krigen.

5. Konklusjon

I denne artikkelen tok vi for oss NoSuchMethodError. Vi diskuterte årsaken til denne feilen og også måter å håndtere den på. For mer informasjon om hvordan du håndterer feil riktig, se artikkelen vår om å fange Java-feil.

Som alltid er koden presentert i denne artikkelen tilgjengelig på GitHub.