4 stelliger int

[davidM]

Hallo erst mal an alle

Es geht um folgendes:

Habe eine Methode in der ich als Parameter Int Hausnummer mitbekomme.
Würde nun gerne überprüfen ob dieser Parameter 4 Stellen hat.
Wie tue ich das

thx david

 

[Wildcard]

1. Möglichkeit:
durch 1000 teilen und prüfen ob ergebnis >=1
1.Möglichkeit
einen String draus machen

 

[SlaterB]

> 999 && <10000


negative Zahlen erlaubt?

 

[Wildcard]

Achso... genau 4 Stellen... Ja, dann nimm SlaterB's Lösung

 

[davidM]

mhh irgendwie "gefällt" mir diese lösung nich, gibts keine vordefinierte methode ala length oder sowas?

mfg david

 

[Wildcard]

Gibt bei int keinen Sinn, da die Länge von der verwendeten Basis abhängt und daher reine Darstellungssache ist.
Ob sie dir gefällt oder nicht, so geht's.

 

[Fatal Error]

nein gibt es für ne integer nicht, sie ist kein Objekt und hat somit auch keine methoden.

 

[davidM]

okay dann werd ich mich wohl damit anfreunden müssen :bae:
danke schon mal für die schnellen antworten

hätte da aber noch was aufm herzen

und zwar habe ich einen konstruktor bsp Artikel(int bestand, String bezeichnung)
nun hab ich mir sagen lassen dass man um inkonsistenz zu vermeiden assertions benutzen sollte um eventuelle "fehlbestückungen" zu vermeiden sodass gar kein fehlerhaftes objekt erzeugt wird (bsp. ohne angabe von bestand oder negativer bestand etc.).

das sähe dann ja so aus:

Public Artikel(int bestand, String bezeichnung) {
 assert (bezeichnung != null) &&  (bezeichnung.trim().length() > 0) :  FEHLERBEZEICHNUNG;

nun zu meiner eigentlichen frage, kann ich dies genau so gut mittels exeptions lösen?
sprich, wird durch benutzen von exceptions auch das anlegen einses objektes "abgebrochen" so wie bei den zusicherungen oder wird einfach nur die exception geworfen un das objekt trotzdem fehlerhaft erzeugt?
wie sähe die lösung mittels exceptions aus?
etwa so?

Public Artikel(int bestand, String bezeichnung) {
   if ( bezeichnung == null && !(bezeichnung.trim().length() > 0 )) {
     throw ne RuntimeException("FEHLERBEZEICHNUNG");
  }

mfg florian[/code]

 

[SlaterB]

testen?

assert ist ja nun auch kein Zaubermittel,
ich selber weiß nicht was das genau macht, wird aber doch wohl irgendeine Exception werfen? (testen?)

dann kannst du natürlich genausogut eine andere werfen,
aber welchen Sinn hat das?
ist länger und für andere schwerer verstehbar,

 

[davidM]

es geht eben nicht nur um das bloße werfen einer exception...
denn wenn die zusicherung nicht erfüllt wird, wird erst gar nicht ein "fehlerhaftes" inkonsistentes objekt erzeugt, meine frage war ja ob dies auch auf die zweite art und weise zutrifft.
weiterhin habe ich gelesen dass man assertions hauptsächlich zum testen benutzt und beim ausführen sogar einen extra schalter angeben muss nämlich java -ea KlassenName mit -ea = enable assertions. damit diese überhaupt ausgeführt werden, daher mein bedenken....vllt kann mich da jemand mal aufklären :meld:

mfg

 

[Wildcard]

Exceptions sind das normale Vorgehen.

 

[byte]

Assertions sind nur für den Entwickler der Anwendung gedacht, so dass man bestimmte Fälle prüfen kann oder ausschließen kann. Die sollten aber nicht fürs Fehler Handling der Anwendung mißbraucht werden, weil die halt spätestens in der finalen Version rausfliegen bzw. bei der Ausführung ohne -ea nicht geprüft werden.

 

[SlaterB]

oder man schreibt
java KlassenName minusIhhAhh

und wenn dieser Paramter gesetzt oder nicht gesetzt wird (in der main prüfen)
dann schaltest du deine eigenen Exceptions ein oder aus

if (useMyAssertions) {
  if ( bezeichnung == null && !(bezeichnung.trim().length() > 0 )) {
     throw ne RuntimeException("FEHLERBEZEICHNUNG");
  } 
}

auch wieder nachgebaut
der Aufwand, ein Boolean zu prüfen, ist so gering, dass man über Performanceunterschied zu Assert wohl nicht nachdenken muss, falls überhaupt einer da ist,


aber ist halt nur ein Parameter,
so eine schöne Java-Option vor dem Klassenname kriegt man wohl auf die Schnelle nicht hin..

---------

bei Exception im Konstruktor wird ein Objekt nicht erzeugt (die Frage komplett überlesen)
bzw. ist danach jedenfalls in keiner Form greifbar,

das dürfte bei eigenen Exceptions und assert gleich sein und auch gleich durchgeführt werden (throw Exception)
dürfte auch bei beiden zur gleichen Stelle IM Konstruktor geprüft werden, behaupte ich mal,
also z.B. nach dem Durchlauf des super-Konstruktors bei Vererbung

aber eine RuntimeException sollte doch eh zum Programmende führen,
das ist die Erzeugung eines Objektes wohl egal?

 

[Gast]

assertions solltest du in situationen einsetzen die nicht vorkommen dürfen, also wenn der parameter niemals null sein darf kannst du da ne assertion hin machen

und falls es dann doch passiert weisst du das du nen programmfehler hast, da diese situation nie eintreffen durfte

 

[SnooP]

genau... Stichwort Vor- und Nachbedingungen