Si es así…seguro que es ‘false’
Analizando la función IsNumeric de VB.Net, me encontré con algo interesante para contar. Los Try - Catch se deben ocupar en situaciones inesperadas, o eso es lo que me enseñaron.
Aquà les pego la función IsNumeric que millones de veces la habrá utilizado alguién que programó en VB alguna vez. Si la quieren mirar está en la clase Microsoft.VisualBasic.CompilerServices.Versioned.
case TypeCode.String:
{
double num1;
string text1 = convertible1.ToString(null);
try
{
long num2;
if (Utils.IsHexOrOctValue(text1, ref num2))
{
return true;
}
}
catch (FormatException)
{
return false;
}
return Conversions.TryParseDouble(text1, ref num1);
}
Explico un poco, si el resultado de la función es true, es Numérico, sino, no lo es.
Tomando como premisa de que solamente se pone Try-Catch en situaciones inesperadas…arribo a la conclusión de que el muchacho/a puede haber estado en una de estas opciones:
1) El que programó IsNumeric, no confia en su compañero que escribió IsHexOrOctValue o no confiá en si mismo que es peor. Hasta un goto aparece en IsHexOrOctValue.
2) Con ciertas cadenas IsHexOrOctValue genera excepciones…serán malas palabras ?
3) Es un tipo muy precavido. Algo tan tonto si llegase a generar una excepción, puede incomodar al programador.
4) Se olvidó de sacarle el Try-Catch: “ups…my mistake”
5) Quien va a mirar mi código ? !
6) Realmente no es tanta la sobrecarga que generan los Try-Catch, es decir, esto no le va a ser mal a nadie.
7) No tenÃa ni idea de la sobrecarga de los Try-Catch.
8 ) Ninguna de las anteriores…se le antojó un Try-Catch y punto!
9) Está super justificado el Try-Catch.
Conclusión:
Este post no es para crÃticar al hombre que escribió el IsNumeric, sino que viendo este trozo de código me puse a pensar de que muchas veces ponemos Try-Catch justificando con: “es por las dudas, mirá si pasa algo!”, y realmente no se justifica el costo de sobrecarga en el sistema, por un “por las dudas”. O incluso peor! Utilizamos los Try-Catch como If diciendo: “y bueno…si falla…seguro que es la otra opción”, y eso no es programar pragmáticamente.
Meditemos un poco como programamos. Saludos
Aqui está toda la función IsNumeric:
public static bool IsNumeric(object Expression)
{
IConvertible convertible1 = Expression as IConvertible;
if (convertible1 != null)
{
switch (convertible1.GetTypeCode())
{
case TypeCode.Boolean:
return true;
case TypeCode.Char:
case TypeCode.String:
{
double num1;
string text1 = convertible1.ToString(null);
try
{
long num2;
if (Utils.IsHexOrOctValue(text1, ref num2))
{
return true;
}
}
catch (FormatException)
{
return false;
}
return Conversions.TryParseDouble(text1, ref num1);
}
case TypeCode.SByte:
case TypeCode.Byte:
case TypeCode.Int16:
case TypeCode.UInt16:
case TypeCode.Int32:
case TypeCode.UInt32:
case TypeCode.Int64:
case TypeCode.UInt64:
case TypeCode.Single:
case TypeCode.Double:
case TypeCode.Decimal:
return true;
}
}
return false;
}
Voy a responder una a una lo que yo pienso:
1) El que programó IsNumeric, no confia en su compañero que escribió IsHexOrOctValue o no confiá en si mismo que es peor. Hasta un goto aparece en IsHexOrOctValue.
> No esta mal programar a la defensiva, ademas IsHexOrOctValue puede arrojar esa excepcion, lo importante es que IsNumeric devuelve true o false, que es lo que dice la documentacion
El goto no es una mala tecnica de programacion, yo creo que puede simplificar algunos escenarios complejos, aunque no lo uso, deberia tenerlo mas en cuenta. Pero nada es bueno mal usado…
2) Con ciertas cadenas IsHexOrOctValue genera excepciones…serán malas palabras ?
La documentacion de IsHexOrOctValue no esta disponible, ademas es internal, tiene una interfaz rara, fijate que tambien devuelve el valor. Parece algo asi como si es un numero hexa o octal dame el numero si no es nada dame false y sino dame un format exception.
3) Es un tipo muy precavido. Algo tan tonto si llegase a generar una excepción, puede incomodar al programador.
Obvio que me incomoda, si el fw tira una excepcion y no esta documentada es algo que no me va a gustar.
4) Se olvidó de sacarle el Try-Catch: “ups…my mistakeâ€
Esta a proposito
5) Quien va a mirar mi código ? !
Dario, claro :D, y el jefe, si tiraba una excepcion.
6) Realmente no es tanta la sobrecarga que generan los Try-Catch, es decir, esto no le va a ser mal a nadie.
Aqui ya se puede hablar un poco mas, el mundo no es perfecto, fijate que en C# tenias Parse nomas y metias un try por si no era, ahora usas TryParse que devuelve null y de paso hace el Parse, pero no quiere decir que una excepcion se esta capturando por ahi.
7) No tenÃa ni idea de la sobrecarga de los Try-Catch.
Esto es subjetivo el try genera sobrecarga solo si la excepcion se captura, sino hay excepcion no, por otra parte de alguna manera tiene que aceptar lo que sea que acepta IsHexOrNumeric y tiene dos opciones, programar un IshexOrNumeric nuevo o usar el que ya hay.
8 ) Ninguna de las anteriores…se le antojó un Try-Catch y punto!
9) Está super justificado el Try-Catch.
No me gusta basic, y visual basic .net menos, ademas tiene una carga muy grande sobre su espalda basic. O sea, VB.Net fue concebido para ser lo mas compatible posible con su predecesor, creo que IsNumeric se llama sin poner nada a la izquierda, asi a secas, eso en un C# no se ve.
Por ahi muchas cosas de CompilerServices sean justamente para eso, y la performance (en el caso de que surgan excepciones) no deberia ser un gran milestone (como el de que ande).
Ya que estamos, te puedo citar lugares del framework que tienen problemas peores, tantos que por ahi me da miedo agarrar el reflector, fijate en la DataBindingNavigator los encapsuladores de los eventos “On () ” son private, se supone que tienen que ser protected virtual, sino ni gracia que siquiera existan los OnClick si la clase base no los puede llamar / sobreescribir…
Saludos