webForumDet fria alternativet

Wrapper för ServerSocket

11 svar · 431 visningar · startad av SPiN

SPiNMedlem sedan mars 20005 832 inlägg
#1

Hej!

Jag sitter och pular med en wrapperclass för java.net.ServerSocket, men det vill sig inte riktigt.

import java.io.*;
import java.net.*;

public class WrapperServerSocket extends ServerSocket {
	public WrapperServerSocket ( int port ) throws IOException {
		super ( port );
	}

	public Socket accept () {
		// Gör mitt eget
	}
	...
}

Varför får jag följande felmeddelande?

Missing return statement;
public Socket accept () {

Jag föredrog att extenda klassen ServerSocket, istället för att använda en instans av den. Vilket är egentligen att föredra? Jag kanske tycker fel, om jag tycker att man bör extenda klassen, eftersom att man slipper skriva i "tomma" metoder i sin wrapperclass - för att kunna använda dem från orginalklassen?

MvH,

------------------
SPiN, bjorne.w@telia.com

-- Wise men talk because they have something to say; fools, because they have to say something. --

sgtpepperMedlem sedan apr. 20005 524 inlägg
#2

Du har gjort helt rätt, felet du får beror helt enkelt på att du i din implementation av accept() ännu inte returnerar något.

accept() skall ju returnera en Socket och just nu gör den inte det, därav felet. Langa in en return null för att slippa felet tills dess att du verkligen har en Socket att returnera.

------------------
Peer's Law
The solution to a problem changes the problem.

UlfTMedlem sedan maj 20016 050 inlägg
#3

Du måste returnera en socket. I din metod accept(), måste du ha åtminstone en sats typ "return variabelAvSocketTyp;", för du har ju deklarerat att metoden ska returnera socket.

När det gäller din andra fråga hänger jag inte med på vad du menar. Någon instansiering måste du ju göra i vilket fall som helst, oavsett om du väljer att instansiera ServerSocket, eller den klass som har ärvt från ServerSocket.

------------------
Två vägar till framgång:

  1. Avslöja inte dina hemligheter.
SPiNMedlem sedan mars 20005 832 inlägg
#4

:x

Det var ju lite klantigt, tack för påminnelsen. :)

UlfT> Ang. nummer 2. Måste ha en instans? Jag menar alltså i själva wrapperclassen, där kan man antingen välja att använda en instans av java.net.ServerSocket, eller extenda, utöka, ServerSocket med min egen klass.

Studera dessa två exempel, som det översta gjorde jag först - innan jag tyckte att en utökning skulle vara bättre:

public class WrapperServerSocket {
	private ServerSocket serverSocket;

	public WrapperServerSocket ( int port ) {
		this.serverSocket = new ServerSocket ( port );
	}

	public Socket accept () {
		return this.serverSocket.accept ();
	}
}

-----------

public class WrapperServerSocket extends ServerSocket {
	public WrapperServerSocket ( int port ) throws IOException {
		super ( port );
	}
}

Båda två funkar ju likadant, men i exempel två med utökningen slipper man de s.k. "tomma" metoderna som endast fungerar som en repeater - den skickar vidare anropet till en instans av ServerSocket. :)

------------------
SPiN, bjorne.w@telia.com

-- Wise men talk because they have something to say; fools, because they have to say something. --

SPiNMedlem sedan mars 20005 832 inlägg
#5

Jaha, tillbaks med fler frågor. :)

Jag har gjort en Stack-klass till samma projekt, och tänkte nu fixa till med excetions om det blir något fel i stacken.

De Stackexceptions som jag har i huvudet just nu är FullStackException och EmptyStackException.

Tänker jag rätt om jag gör så här:
<font size="1" face="Verdana, Arial, Helvetica, sans-serif">Kod:<font size="1" face="Verdana, Arial, Helvetica, sans-serif" color="#666600">
...
public void push ( Type variable ) {
  if ( isFull () ) {
    throw new FullStackException ();
  ...
}
...

<font size="1" face="Verdana, Arial, Helvetica, sans-serif">Kod:<font size="1" face="Verdana, Arial, Helvetica, sans-serif" color="#666600">
class StackException extends Exception {

}

class FullStackException extends StackException {

}

Gör man så? Hur skulle klasserna för StackException och FullStackException kunna se ut? Jag har aldrig programmerat på det här sättet, så skulle vara superglad för lite hjälp! :)

------------------
SPiN, bjorne.w@telia.com

-- Wise men talk because they have something to say; fools, because they have to say something. --

[Redigerat av SPiN den 27 jan 2002]

sgtpepperMedlem sedan apr. 20005 524 inlägg
#6

Tänker jag rätt om jag gör så här:

Jepp!

Du måste också deklarera att t.ex metoden push() kan slänga ett FullStackException genom att definera metoden så här:
<font size="1" face="Verdana, Arial, Helvetica, sans-serif">Kod:<font size="1" face="Verdana, Arial, Helvetica, sans-serif" color="#666600">
public void push ( ) throws FullStackException {
....
}

Du kan även deklarera att en metod kan slänga fler än ett undantag genom att separera dom med kommatecken, t.ex:
<font size="1" face="Verdana, Arial, Helvetica, sans-serif">Kod:<font size="1" face="Verdana, Arial, Helvetica, sans-serif" color="#666600">
public void push ( ) throws FullStackException, StackException {
....
}

Hur skulle klasserna för StackException och FullStackException kunna se ut?

Dom behöver i princip inte överlagra någon metod, huvudsaken är att du i din catch-sats kan identifiera att det just är t.ex ett FullStackException som skett, men du kan ju göra en egen getMessage()-metod som returnerar lämpligt meddelande.

------------------
Peer's Law
The solution to a problem changes the problem.

SPiNMedlem sedan mars 20005 832 inlägg
#7

Ah! Danke! Du är ju kung, schassen! :)

spangoMedlem sedan juni 20006 147 inlägg
#8

Personligen skulle jag nog gjort så att FullStackException och EmptyStackException ärver från RuntimeException, så man slipper fånga dem, och sedan innan användningen kollar om stacken är full/tom.

------------------
Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

SPiNMedlem sedan mars 20005 832 inlägg
#9

Pga att man slipper fånga dem då? Eller finns det flera fördelar?

Jag kom att tänka på, att om man istället för att kasta ett exception, så skulle man kunna returnera null-värde. På så sätt skulle man kunna bygga upp en liknande loop:
<font size="1" face="Verdana, Arial, Helvetica, sans-serif">Kod:<font size="1" face="Verdana, Arial, Helvetica, sans-serif" color="#666600">
while ( ( Object object = stack.pop () ) != null ) {
...

Vilket är att föredra?

LimeMedlem sedan sep. 2001837 inlägg
#10

Jag skulle föredra att man kastade ett "EmptyStackException". Annar måste man hela tiden kolla om det är som returneras. Det innebär mindre effektiv kod. Om man hela tiden kollar om det är ett visst värde (!=null) så görs det varje gång.

Kastar man ett exception så tar errorhandlern hand om detta och catch-koden anropas bara när det verkligen behövs.

Sedan kan man fundera på om StackExceptions är Runtime-exceptions. Runtime-exception skall användas när det är fel som gör att programmet inte längre kan köra.

Om man då har en stack som man fyller på med värden, säg 101 stycken (instanser av objektet Dalmatian) via ett gui och man kan poppa bort dom med en knapp och se hur dom blir pälsar istället, men råkar trycka 102 gånger (så man får en uppföljare :-) ), då vill man inte att programmet skall kasta ett runtime och dö bara för att man fått slut på vovvar...

/Lime

------------------
Praeterea conseo microsoftenem esse delendam.
- modernt latinskt ordspråk

SPiNMedlem sedan mars 20005 832 inlägg
#11

Tackar, nu klarnade det lite mer! Fasen, man ligger ju i lä när det gäller Java här, det här är nog ett av de forum på wF med störst kompetens! :)

------------------
SPiN, bjorne.w@telia.com

[Redigerat av SPiN den 29 jan 2002]

spangoMedlem sedan juni 20006 147 inlägg
#12

Sedan kan man fundera på om StackExceptions är Runtime-exceptions. Runtime-exception skall användas när det är fel som gör att programmet inte längre kan köra.

Fast å andra sidan är IndexException subklass till RuntimeException, och det känns som att EmptyStackException är nära besläktat med IndexException. Liksom.

------------------
Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Genererad på 520 ms · cache AV · v20260730165559-full.f96bc7eb