# String zu BigInteger



## nixe (11. Mai 2004)

Wie kann ich aus nem String nen BigInteger machen?


----------



## L-ectron-X (11. Mai 2004)

```
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 (11. Mai 2004)

L-ectron-X hat gesagt.:
			
		

> Kann man alles in der API-Dok erlesen.


Und die findet man hier.


----------



## nixe (11. Mai 2004)

Danke!!!


----------



## Mizus (12. Mai 2004)

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 (12. Mai 2004)

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 (12. Mai 2004)

danke... :toll:


----------



## neurox (14. Sep 2009)

L-ectron-X hat gesagt.:


> ```
> 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 (14. Sep 2009)

neurox hat gesagt.:


> 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 (14. Sep 2009)

maki hat gesagt.:


> 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 (14. Sep 2009)

> 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 (14. Sep 2009)

maki hat gesagt.:


> 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 (14. Sep 2009)

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- (14. Sep 2009)

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 (14. Sep 2009)

maki hat gesagt.:


> 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!!


----------

