URL klasse

Der skal enten en try catch omkring eller en throws på metoden.

import java.net.MalformedURLException;
import java.net.URL;

public class Ex {
    public void m1() throws MalformedURLException {
        URL url = new URL("http://www.google.com/index.html");
    }
    public void m2() {
        try {
            URL url = new URL("http://www.google.com/index.html");
        } catch (MalformedURLException e) {
            e.printStackTrace();
        } 
    }
}

Mit spg. gik mere paa, hvorfor kaster den en exception. Url'en eksisterer... skal man registrere http protokollen saaledes at URL klassen kan genkende den?

Den smider vel ikke den exception når programmet køres. Det er vel en compile time fejl.

URL constructor kunne smide den exception (f.eks. ved "foo://bar"). Og compileren checker ikke strengen men kun constructor signatur.

Jeg kommer fra .net verdenen, og er meget groen til java. Er faktisk lige startet idag. Exceptionen bliver smidt under runtime og linien understreges under compile time med meddelelsen MalformedURLException.

Skal man i Java proppe funktionskald i try catch blokke hvis funktionen kan smide en exception? Er det det som er fejlen?

Ja, i Java skal du generelt håndtere exceptions, og compileren hjælper dig med det. I .NET verdenen behøver du ikke.

Man kan diskutere hvad der er bedst. Argumentet for at skulle håndtere exceptions er, at man bliver tvunget til at tage stilling til hvad der skal ske, når der opstår fejl under kørsel. Det sikrer i princippet robuste programmer.

Test viser at det er saadanne det virker. Svar => point.

Efter lidt tilvaenning, saa er det faktisk meget smart. Man kan ikke undlade at tage stilling til fejl.

Bemaerk at Java har en undtagelse - exceptions der arver fra RuntimeException skal ikke haandteres paa denne maade.

"Man kan ikke undlade at tage stilling til fejl." - principielt korrekt, men praksis er måske anderledes.

Det er bøvlet, og ikke nemt, at håndtere exceptions, så man ser af og til (ofte?)

        try {
            //....noget
        } catch (Exception e) {
        } 

...altså: man har li'som taget hensyn til det, men kun for at få compileren til at holde mund. Derved kan der så opstå fejl andre steder i programmet, som er svære at fange.

Med moderne IDE'er er det nemt at få sat de specifikke exceptions ind.

Og selvom håndteringen ikke altid er optimal, så fremgår det ihvertfald klart af koden at der er et problem.

Der er mange skrækhistorier om hvor galt det kan gå med brug af checked exceptions. Men jeg synes ikke at man ser de scenarier i den virkelige verden.

En af de store fordele ved checked exceptions er naar man definerer et interface foerst med nogle givne exceptions, saa kan klasserne der implementerer kun smide de (checked) exceptions og kalder faar dermed et noget mere stabilt interface, hvor man netop kan undgaa at skulle catche Exception.

Svar => point.

svar

Jeg gaetter paa at Erik ikke vil have point.