Saltar al contenido

String.valueOf() frente a Object.toString()

Hacemos una verificación completa cada escrito en nuestra web con el objetivo de enseñarte siempre información con la mayor veracidad y certera.

Solución:

Según la documentación de Java, String.valueOf() devoluciones:

si el argumento es nullEntonces un string igual a "null"; de lo contrario, el valor de obj.toString() es regresado.

Entonces, realmente no debería haber una diferencia, excepto por la invocación de un método adicional.

Asimismo, en el caso de Object#toStringsi la instancia es nulla NullPointerException será arrojado, por lo que podría decirse que es menos a salvo.

public static void main(String args[])   
    String str = null;
    System.out.println(String.valueOf(str));  // This will print a String equal to "null"        
    System.out.println(str.toString()); // This will throw a NullPointerException
 

Las diferencias entre String.valueOf(Object) y Object.toString() son:

1)Si string es null,

String.valueOf(Object) regresará nullmientras que Object::toString() lanzará un null excepción de puntero.

public static void main(String args[])  
    String str = null;

    System.out.println(String.valueOf(str));  // it will print null        
    System.out.println(str.toString()); // it will throw NullPointerException        
  

2) Firma:

El método valueOf() de la clase String es static. mientras que el método toString() de la clase String no es static.

La firma o sintaxis de stringEl método valueOf() se proporciona a continuación:

public static String valueOf(boolean b)  
public static String valueOf(char c)  
public static String valueOf(char[] c)  
public static String valueOf(int i)  
public static String valueOf(long l)  
public static String valueOf(float f)  
public static String valueOf(double d)  
public static String valueOf(Object o)

La firma o sintaxis de string’s toString() método se da a continuación:

public String toString()

En Java, ¿hay alguna diferencia entre String.valueOf(Object) y Object.toString()?

Si. (¡Y más si consideras sobrecargar!)

Como explica el javadoc, String.valueOf((Object) null) será tratado como un caso especial por la valueOf método y el valor "null" es regresado. Por el contrario, null.toString() solo le dará un NPE.

Sobrecarga

Resulta que String.valueOf(null) (nota la diferencia!) lo hace dar un NPE … a pesar del javadoc. la verdadera explicación1 es oscuro:

  1. Hay una serie de sobrecargas de String.valueOfpero hay dos que son relevantes aquí: String.valueOf(Object) y String.valueOf(char[]).

  2. en la expresión String.valueOf(null)ambas sobrecargas son aplicableya que null la asignación es compatible con cualquier tipo de referencia.

  3. Cuando hay dos o más aplicable sobrecargas, el JLS dice que la sobrecarga para el más específico se elige el tipo de argumento.

  4. Ya que char[] es un subtipo de Objectestá mas especifico.

  5. Por lo tanto, los String.valueOf(char[]) se llama sobrecarga.

  6. String.valueOf(char[]) lanza un NPE si su argumento es un null array. a diferencia de String.valueOf(Object)no trata null como un caso especial.

Otro ejemplo ilustra la diferencia en el valueOf(char[]) sobrecarga aún más claramente:

char[] abc = new char[]('a', 'b', 'c');
System.out.println(String.valueOf(abc));  // prints "abc"
System.out.println(abc.toString());       // prints "[[email protected]"

¿Existe una convención de código específica para estos?

No.

Use el que sea más apropiado para los requisitos del contexto en el que lo está usando. (Vos si necesitar el formato para trabajar null?)

Nota: esa no es una convención de código. Es solo programación de sentido común. Está más importante que tu código es correcto que seguir alguna convención estilística o dogma de “mejores prácticas”2.


1 – Puede confirmar esto usando javap -c para examinar el código de un método que tiene un String.valueOf(null) llamada. Observe la sobrecarga que se utiliza para la llamada.

2 – Lea “No hay mejores prácticas” y pase esta referencia a la siguiente persona que le diga que es una “mejor práctica” hacer algo en los dominios de programación o TI.


Opinión personal

Algunos desarrolladores adquieren el mal hábito (en mi opinión) de “defenderse” de los valores nulos. Por lo tanto, verá muchas pruebas para valores nulos y tratará los valores nulos como casos especiales. La idea parece ser evitar que ocurra NPE.

Creo que esto es una mala idea. En particular, creo que es una mala idea si lo que haces cuando encuentras un null es tratar de “hacer el bien” … sin considerar por qué hubo un null allí.

En general, es mejor evitar la null estar allí en primer lugar… a menos que el null tiene un significado muy específico en su aplicación o diseño de API. Por lo tanto, en lugar de evitar la NPE con mucha codificación defensiva, es mejor dejar que ocurra la NPE y luego rastrear y corregir la fuente de lo inesperado. null que desencadenó la NPE.

Entonces, ¿cómo se aplica esto aquí?

Bueno, si lo piensas bien, usar String.valueOf(obj)pudo ser una forma de “hacer el bien”. Eso hay que evitarlo. Si es inesperado para obj ser null en el contexto, es mejor usar obj.toString().

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *