String zu BigInteger

[nixe]

Wie kann ich aus nem String nen BigInteger machen?

 

[L-ectron-X]

String str = "123456789";
java.math.BigInteger bi = new java.math.BigInteger(str);

Du kannst dem Konstruktor von BigInteger schon den String übergeben. Dieser liefert dann ein BigInteger-Objekt zurück. Kann man alles in der API-Dok erlesen.

 

[P3AC3MAK3R]

Kann man alles in der API-Dok erlesen.

Und die findet man hier.

 

[nixe]

Danke!!!

 

[Mizus]

Ist BigInteger was anderes als Integer ???:L

Bitte jetzt nicht falsch verstehen meine nicht int sondern Integer

Sonst konnte man doch auch

Integer.valueOf(String s);

oder ist das was anders... wenn ja wo ist dann der Unterschied ???:L

 

[Roar]

BigInteger ist - wie der name schon sagt - größer als Integer. Integer ist nur ne Wrapperklasse für int. BigInteger hat nen größeren Zhalenbereicht, wenn ich mich nicht täusche.

 

[Mizus]

danke... :toll:

 

[neurox]

String str = "123456789";
java.math.BigInteger bi = new java.math.BigInteger(str);

Du kannst dem Konstruktor von BigInteger schon den String übergeben. Dieser liefert dann ein BigInteger-Objekt zurück. Kann man alles in der API-Dok erlesen.

Kann mir jemand sagen, wie ich einen String auf seine Konvertierbarkeit nach BigInteger hin testen kann, OHNE eine NumberFormatException werfen zu lassen?

 

[maki]

Kann mir jemand sagen, wie ich einen String auf seine Konvertierbarkeit nach BigInteger hin testen kann, OHNE eine NumberFormatException werfen zu lassen?

Wär doch sinnfrei, das Rad nochmal nue zu erfinden, oder?
Denn genau dafür ist doch die NumberFormatException da...
Am besten du fängst die NumberFormatException und reagierst darauf.

 

[neurox]

Wär doch sinnfrei, das Rad nochmal nue zu erfinden, oder?
Denn genau dafür ist doch die NumberFormatException da...
Am besten du fängst die NumberFormatException und reagierst darauf.

So sinnfrei finde ich das gar nicht. Exceptions sind Ausnahmen und sollten nicht zur Regel gemacht, also in die normale Programmlogik eingebaut werden. Das ist unsauber.

In diesen Fall erwarte ich ja schon quasi, dass ein String gar keine Zahl ist. Ich möchte an dieser Stelle einfach nur wissen, ob ich es mit einer Zahl zu tun habe, oder nicht, damit ich im weiteren Verlauf die richtige Entscheidung treffen kann.

 

[maki]

So sinnfrei finde ich das gar nicht. Exceptions sind Ausnahmen und sollten nicht zur Regel gemacht, also in die normale Programmlogik eingebaut werden. Das ist unsauber.

Nein, pauschal unsauber ist das nicht, du musst ja nicht die NFE werfen und dann dein Progamm abbrechen

Einfach eine Methode schireben die einen String als Parameter hat und einen boolean zurückgibt, die Methode darf dann auch zB. [c]isValidBigInteger[/c] heissen.
In der Methode dann dein try/catch Block, ca. 4-5 Zeilen insgesamt

 

[neurox]

Nein, pauschal unsauber ist das nicht, du musst ja nicht die NFE werfen und dann dein Progamm abbrechen

Einfach eine Methode schireben die einen String als Parameter hat und einen boolean zurückgibt, die Methode darf dann auch zB. [c]isValidBigInteger[/c] heissen.
In der Methode dann dein try/catch Block, ca. 4-5 Zeilen insgesamt

Habe mir gerade noch mal verschiedene Lösungswege angeschaut. Dein Vorschlag scheint wirklich gänige Praxis zu sein. Aber ich denke mal ich werde den String doch lieber per Regex prüfen, oder spricht da etwas dagegen? Die NFE kann ich ja immer noch abfangen.

Danke für den Tipp!

 

[maki]

Was gegen RegEx spricht?
RegEx sind komplex, die Chance dass man da Fehler einbaut (also sog. "false positives" bekommt) ist recht hoch, ausserdem müsste die RegEx ganuso funktionieren muss wie value(..) bzw. parse..(..) -> Redundanz
Dazu kommt dass RegEx eine zus. Sprache darstellen, und damit die Komplexität vom Quellcode auch wieder steigt und mehr Chancen für Fehler vorhanden sind.

 

[-MacNuke-]

Gerade bei den Number-Klassen (BigInteger, BigDecimal) musst du die Exceptions fangen. Du musst auch aufpassen wie dein BigInteger/BigDecimal konfiguriert ist. Weil bei einem Unlimited BigDecimal mal eben 1 durch 3 teilst, dann fliegt dir das Programm um die Ohren

Ich für meinen Teil fange in meinen Textfeldern schon vorher ab, ob die Eingabe eine Zahl ist oder nicht, per DocumentFilter (Swing, aber auch SWT und Webgeschichten bieten solche Filter). Da kann der Nutzer auf dem Alphabet rumhauen wie er will, es werden nur Zahlen akzeptiert. Aber auch hier prüfe ich mit Integer.parseInt(str) und fange die Exception. Ist ja kein Ding, dazu sind die Sachen doch da. Wenn der Kunde "so blöd" ist und bei einem Zahlenfeld Buchstaben eintippen will, ist es eine Ausnahme.

Bei Komma-Feldern wird es aber mit RegExen schwieriger, wegen Komma und Punkt (ist ja International anders) usw. Hierzu ist denn ja NumerFormat da und der wirft Exceptions. Das ist gängige Arbeitsweise

 

[neurox]

Was gegen RegEx spricht?
RegEx sind komplex, die Chance dass man da Fehler einbaut (also sog. "false positives" bekommt) ist recht hoch, ausserdem müsste die RegEx ganuso funktionieren muss wie value(..) bzw. parse..(..) -> Redundanz
Dazu kommt dass RegEx eine zus. Sprache darstellen, und damit die Komplexität vom Quellcode auch wieder steigt und mehr Chancen für Fehler vorhanden sind.

Okay, bin überzeugt. Das Abfangen ist auch schlicht weg die schnellere und definitiv auch die sicherere Lösung, zumal ich die NFE in der Tat ohnehin abfangen muss.

Danke!!