Déclarer un String comme étant de l'héxadécimal

Code:

---

1 2	int b = 0xFF; a = (byte) (b);

---

On ne perd aucune précision, pas d'exception, et la valeur attendue de -1 alors que si on perdait en précision, par exemple à cause du bit de signe, on devrait obtenir comme valeur (127) 7F et pas -1

Mais si on fait:

Code:

---

Byte.parseByte("0xFF", 16);

---

On se prend une exception.

Et là moi ça me chagrine un peu, surtout que c'est un cast 'régulier'

Citation:

---

Envoyé par bulbo

Code:

---

1 2	int b = 0xFF; a = (byte) (b);

---

On ne perd aucune précision, pas d'exception, et la valeur attendue de -1 alors que si on perdait en précision, par exemple à cause du bit de signe, on devrait obtenir comme valeur (127) 7F et pas -1

---

Si il y a perte de précision (255 ca rentre pas dans un byte), non en cas de perte de précision en typecasting, il n'y a pas d'exception en java (de même qu'en cas de débordement), non on ne devrait pas avoir 127. Convertir "255" en byte, ca n'est pas plus correct mathématiquement de prendre 127 que de prendre -1. 2044 convertis en byte donne -4, ce n'est pas mathématiquement correct. C'est bien marqué dans la JLS, si tu dépasse les bornes du type vers lequel tu caste, la valeur ne sera pas préservée, on va juste couper les bits en trop.


Et je le répète ici, on parle de typecasting, ce qui n'a absolument rien à voir avec parseByte qui concerne du parsing de String. D'ailleurs parseByte et totalement cohérent par rapport à parseInt. Maintenant, effectivement, on peux leur reprocher de ne pas être cohérent par rapport au language puisque je peux écrire

Code:

---

1 2 3 4

public static void main(String[] args) throws IOException { int a = 0xFFFFFFFF; Integer.parseInt(String.format("%X", a)); }

---

et que c'est exception garantie
Encore une fois, c'est une librairie, elle a sa doc il suffit de la suivre pour savoir ce qu'on peux faire ou pas.