Keine null-Werte für Methodenparameter

[Guest]

Hallo,

gibt es eine Möglichkeit einen Methodenparameter so zu deklarieren, dass man einen Compilerfehler bekommt, wenn man "null" übergibt?

Bsp.: Ich hätte gerne, dass man für val nicht "null" übergeben darf.

void setValue(Object val)
{
    ...
}

 

[Guest]

ich bin auch noch anfänger, also falls das blödsinn ist was ich schreibe steinigt mich nicht.

ich würde das so probieren. keine ahnung ob das geht...

public void irgendEineAndereMethode(Object o)
{
  if(o != null)
  {
  setValue(o)
  }
}

 

[Sky]

So geht es auch:

void setValue(Object val) { 
  if ( val != null ) {
  }
}

Oder auch

void setValue(Object val) {
  if ( val == null ) {
    throw new NullPointerException();
  } 
  // ...
}

Die Übergabe von NULL läßt sich nicht durch den Compiler überprüfen sondern nur zur Laufzeit, da zur Compile-Zeit i.d.R. nicht prüfbar ist, welchen Wert eine Referenz haben wird.

Ansonsten, wenn Du die Methode so bedienst:

setValue(null);

dann bist Du selbst schuld, wenn sich das Prog. auf die Nase legt ;-)

 

[Bleiglanz]

es kann keinen compilerfehler geben, weil die Tatsache, dass das Argument null ist oder nicht beim Compilieren nicht bekannt ist

verwende assert

 

[Guest]

Danke für eure Antworten!

@Bleiglanz
Wie geht das mit Assert ?

 

[thE_29]

Oder auch so

    public void setValue(Object o) throws NullPointerException
    {
      if(o == null)
        throw new NullPointerException("Object must not be null!!");
    }

Nachtrag: http://www.google.at/search?hl=de&q=assert++java&meta=

bin asserts mal kurz überflogen, finde ich unnötig das Ding und wirklich was bringen tuts auch net!

Sind per Hand geschrieben Routinekontrollen, toll :>

 

[Sky]

Nachtrag: Wenn der Fall oft vor kommt, dass die Methode null übergeben bekommt, so ist das Arbeiten von Exceptions nicht der richtige Weg (ist ja dann keine Ausnahme...). Dann bietet sich noch folgende Variante an:

public boolean setValue( Object o ) {
  if ( o == null ) {
    return false;
  }
  // ...
  return true;
}

Der boolsche Rückgabewert gibt an, ob der übergebene Wert 'o' gesetzt wurde.

 

[bygones]

denke auch asserts sind hier besser angebracht....

mehr dazu : http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

 

[Bleiglanz]

@the_29

asserts sind imho wichtige hilfsmittel

a) lassen sich sich für einen Release Build einfach abschalten

b) du kannst nicht immer und überall einfach Runtime-Exceptions herumwerfen

die Frage zielte ja auf einen Compilerfehler bei Übergabe von null - sowas gibt es aber leider nicht - irgenwie so von der Bauart "der Progger" ist sich sicher, dass von seinen anderen Programmbestandteilen NIE null übergeben wird

=> da baut man immer ein Assert ein, zur Sicherheit; und wirft keine Exception [wo sollte denn die zur Laufzeit abgefangen werden? , unter Umständen wird sie weiter oben im Call-Stack verschluckt usw.]

 

[thE_29]

Naja, ich hab beides noch nie gebraucht, da ich weiß was meine Methoden übergeben

Und wenn mal null kommt, is meistens ne if Abfrage drinnen ;>

Ist einfach schon fast standisiert bei mir, weil manchmal vergeße ich einfach ein new und da ist so ein if null schon recht praktisch

 

[boskop]

von mir aus gesehen, ist es auch nicht unbedingt notwendig eine NullpointerException zu werfen, die kommen von ganz alleine. Sind meine liebsten ;-)

Gruss,

Boskop

 

[bygones]

Naja, ich hab beides noch nie gebraucht, da ich weiß was meine Methoden übergeben

wenn ein Projektleiter mir dieses Argument bringen würde wäre der Vertrag gestorben ^^

es gehören einfach "unabhängige", objektive Tests ala asserts / JUnit dazu....