Problem med kompilering

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).

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?

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

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?

Dom ska helst ärva av basklassen Exception.

Det är en helt vanlig klass.

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 ...).

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()
   {
      ...
   }
}

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?

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å! ;)

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.)