piccoli quiz: DecimalFormat.parse
Davide
1) Stampa 1
2) Lancia una ParseException
3) Stampa 1.2
4) Stampa 11.2
import java.text.DecimalFormat;
import java.text.NumberFormat;
import java.text.ParseException;
public class A
{
public static void main(String[] args) throws ParseException
{
NumberFormat df = DecimalFormat.getNumberInstance();
Number num = df.parse("1x1.2");
System.out.println(num);
}
}
--
_| _. o _| _
(_| (_| \/ | (_| (/_
Simone Bordet
On Fri, Jan 27, 2012 at 20:59, Davide <d...@vide.bz> wrote:
> Cosa succede lanciando il codice allegato:
>
> 1) Stampa 1
> 2) Lancia una ParseException
> 3) Stampa 1.2
> 4) Stampa 11.2
>
>
> import java.text.DecimalFormat;
> import java.text.NumberFormat;
> import java.text.ParseException;
>
> public class A
> {
> public static void main(String[] args) throws ParseException
> {
> NumberFormat df = DecimalFormat.getNumberInstance();
> Number num = df.parse("1x1.2");
> System.out.println(num);
> }
> }
Così a naso e senza guardare i Javadocs direi risposta 1).
Mi pare di ricordare che il parsing ci "prova" e scarta quello che non riesce.
Se fosse stato parse("x1.2") credo avrebbe lanciato una ParseException.
Simon
--
http://cometd.org
http://intalio.com
http://bordet.blogspot.com
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Davide
Hai ragione, è proprio cosí. Il parsing ci prova e restituisce qualcosa. Ho provato a cercare se si può sapere fino a dove è arrivato ma non mi pare. Se così fosse lo trovo un metodo che non userei mai ... l'error hiding antipatttern lo trovo uno dei piu pericolosi ...
--
You received this message because you are subscribed to the Google Groups "JUG Trentino Alto Adige Suedtirol" group.
To post to this group, send email to jug...@googlegroups.com.
To unsubscribe from this group, send email to jugtaa+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jugtaa?hl=en.
Chris Mair
> Hai ragione, è proprio cosí. Il parsing ci prova e restituisce qualcosa. Ho provato a cercare se si può sapere fino a dove è arrivato ma non mi pare. Se così fosse lo trovo un metodo che non userei mai ... l'error hiding antipatttern lo trovo uno dei piu pericolosi ...
Soprendente!
Io ho pensato 2 leggendo la mail (ma non ho avuto
il corraggio di partecipare ;).
Sono d'accordo con te, Davide: questo comportamento
e` molto pericoloso. Nel mondo SQL il solito MySQL
era tristemente noto per questi cast "di fortuna".
Ormai persino MySQL (dalla 5 mi pare), almeno produce
un warning:
mysql> select cast('1x1.2' as signed);
+-------------------------+
| cast('1x1.2' as signed) |
+-------------------------+
| 1 |
+-------------------------+
1 row in set, 1 warning (0.00 sec)
mysql> show warnings;
+---------+------+--------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------+
| Warning | 1292 | Truncated incorrect INTEGER value: '1x1.2' |
+---------+------+--------------------------------------------+
1 row in set (0.00 sec)
Il mio preferito, Postgres, da sempre non lo accetta e
da` errore:
chris=# select cast('1x1.2' as integer);
ERROR: invalid input syntax for integer: "1x1.2"
LINE 1: select cast('1x1.2' as integer);
Mi sorprende veramente che qui Java e` addirittura
piu` sloppy di MySQL (e ci vuole per esserlo ;).
Bye,
chris.