webForumDet fria alternativet

Problem med kompilering

10 svar · 492 visningar · startad av Gein

GeinMedlem sedan sep. 20005 700 inlägg
#1

Har ett gäng interface och har nu skrivit klassfiler som ska implementera dessa interface. Vart någonstans ska interface-filerna ligga? Klassen AbstractEvent implementerar interfacet Event, när jag försöker kompilera AbstractEvent så klagar kompilatorn och säger "cannot access Event". Jag har provat lägga Event i samma katalog som AbstractEvent och har också kompilerat Event.java (utan problem).

spangoMedlem sedan juni 20008 205 inlägg
#2

Det ska inte spela någon roll vilket katalog interfacen ligger i, de ska ligga i sitt pakets katalog, ingen annanstans. Du kan ju prova att ställa sourcepath till katalogen för rotpaketet. Om din källkod ligger i t.ex. src/baspaket/underpkt1/*.java och src/baspaket/underpkt2/*.java och du står i den katalog som src ligger i, kan du säga javac -sourcepath src ... (by ut ellips mot filnamnen).

GeinMedlem sedan sep. 20005 700 inlägg
#3

Felet var att jag för det första inte hade alla filer på rätt ställe och sedan hade jag dessutom blandat lite olika paket. Är helt klart obekant med paketstrukturen ;)

Kan fråga vidare: De givna interfacen har metoder som slutar med throws ... . Hur implementerar jag dessa i klasserna? Som det är nu säger kompilatorn t.ex:

cannot resolve symbol class IllegalPositionException

.
Provade att helt enkelt deklarera funktionen med throws IllegalPositionException i slutet men det gick inte. Hur implementerar man throws?

ViktorMedlem sedan aug. 20021 752 inlägg
#4

Om ditt interface ser ut såhär,

#import xxx.xxx.IllegalPositionException;

public interface ITest
{
    public String getTest()
    throws IllegalPositionException;
}

så betyder det att funktionen getTest kan kasta felet IllegalPositionException, felet IllegalPositionException är en egen klass som ligger i ett paket (du vet bättre var det ligger :)) så i din implementation måste du också importera denna klass,

#import xxx.xxx.IllegalPositionException;

public class Test implements ITest
{
    private String test="Stockholm";

    public String getTest()
    throws IllegalPositionException
    {
        if(test.equals("Stockholm"))
            return(test);
        else
            throw(new IllegalPositionException("Fel stad!!!"));
    }
}

/Viktor

GeinMedlem sedan sep. 20005 700 inlägg
#5

Okej, vi ska alltså skapa klasserna själva förstår jag. T.ex så finns

public void register(Entity en) throws RuntimeException, AlreadyRegisteredException;

Ska exceptions-klasser se ut på ett specifikt sätt?

PhorpherMedlem sedan feb. 20002 300 inlägg
#6

Dom ska helst ärva av basklassen Exception.

Det är en helt vanlig klass.

GeinMedlem sedan sep. 20005 700 inlägg
#7

Okej, men den lär väl inte innehålla speciellt mycket, om ens något öht? Det ska väl bara vara ett objekt?

Vad är skillnaden på:
public void register(Entity en) throws RuntimeException, AlreadyRegisteredException;
och public void remove(Entity en) throws NoSuchEntityException;?

red/ Provade att helt sonika skapa en SimulationsExceptions.java och i denna klass skapade jag sedan ett exceptions som finns:

package simulation;

public class SimulationExceptions extends Exception{
	
	public class NoSuchEntityException extends SimulationExceptions {
		
		public NoSuchEntityException() {}
	}
}

Får dock fortfarande samma fel för NoSuchEntityException (dvs, cannot resolv symbol class ...).

PhorpherMedlem sedan feb. 20002 300 inlägg
#8

NoSuchEntityException blir i det där fallet en inre-klass. Det är inget du vill ha.

Om du vill samla alla dina exceptions under en basexception så gör du som du gjort, nästan.

SimulationExceptions.java


package simulation;

public class SimulationExceptions extends Exception
{
   public SimulationExceptions
   {
      ...
   }
}

NoSuchEntityException.java

public class NoSuchEntityException extends SimulationExceptions
{
   public NoSuchEntityException()
   {
      ...
   }
}
GeinMedlem sedan sep. 20005 700 inlägg
#9

Tanken med min SimulationExceptions var att få samla alla exceptions under en och samma fil... men det var visst inte så enkelt. Det går alltså om jag skapar en ny fil NoSuchEn... som du skriver men jag struntade i att ärva från SimulationExceptions utan istället direkt från Exceptions. Men på detta vis så blir det ju en fil för varje exceptions... tycker det är helt orimligt. Och interfacen får jag inte definiera om så, jag antar att det inte finns en lösning på det problemet?

PhorpherMedlem sedan feb. 20002 300 inlägg
#10

Det är korrekt. En fil för varje exception. Sån är javas struktur.

Det GÅR förvisso att ha flera klasser i samma fil om bara en av klasserna deklareras public.

public class A
{
   ...
}

class B
{
   ...
}

class C
{
   ...
}

Fast då går du emot SUN's kodkonventioner och dom vill man hålla på! ;)

spangoMedlem sedan juni 20008 205 inlägg
#11

Gein skrev:

Okej, men den lär väl inte innehålla speciellt mycket, om ens något öht? Det ska väl bara vara ett objekt?

Ibland kan man vilja att undantaget innehåller information om problemet som uppstod. T.ex. skulle man kunna tänka sig att AlreadyRegisteredException har en referens till den Entity man försökt regga fler gånger. (Eller så låter man bli det. Det brukar jag göra. Den specifika klassen på exceptions är mest en markering av vad som gick snett.)

134 ms totalt · 3 externa anrop · v20260731065814-full.30151723
0 ms — hämta forumlista (cache)
0 ms — hämta statistik (cache)
131 ms — hämta tråd, inlägg och bilagor (db)