Conversiones en Visual Basic 2005

En Visual Basic 2005, como en la mayoría de los actuales lenguajes orientados a objetos y, en particular, aquellos que generan aplicaciones para la plataforma .NET, las variables que van a contener referencias a objetos se declaran con un tipo concreto, lo cual facilita su uso porque al conocerse el tipo durante la fase de diseño, el compilador puede efectuar comprobaciones estrictas y evitar ciertos tipos de errores. En ocasiones, sin embargo, nos encontraremos en la necesidad de convertir referencias genéricas, de tipo Object, a tipos concretos. Es lo que ocurre, por ejemplo, al recuperar objetos almacenados en listas, controles ListBox o TreeView, o bien ciertas estructuras de datos, como ArrayList.

En Visual Basic 6 la conversión de tipos se llevaba a cabo con la función CType(), mientras que en Visual Basic .NET apareció la función DirectCast(). Ambas se comportan de manera similar y permiten efectuar una conversión de tipo siempre que exista una relación, ya sea de herencia entre clases o de interfaces, entre el tipo real del objeto y el tipo al que quiere convertirse. Si esa conversión no es posible, ambas funciones producen una excepción. En la práctica esto nos obliga a utilizar un bloque Try/Catch, para controlar la posible excepción, siempre que vayamos a intentar una conversión.

En Visual Basic 2005 existe una alternativa: la función TryCast(). Ésta también convierte referencias a objetos de unos tipos a otros, pero si la conversión no es posible no se genera excepción alguna, sino que simplemente se devuelve el valor Nothing. Esto nos permite escribir código como el siguiente:

objeto = TryCast(genérico, específico)
If objeto IsNot Nothing Then
  objeto.método
End If

No es necesario, por tanto, utilizar el control estructurado de excepciones para evitar que, si la conversión falla, el programa pueda llegar a interrumpir su ejecución.

My.Computer.Network

Al crear aplicaciones .NET con Visual Basic 2005 tenemos a nuestro alcance un recurso, el espacio de nombres My, mediante el cual podemos resumir en unas pocas sentencias procesos que, en otros lenguajes como C# o C++, precisarían decenas o cientos de líneas de código. Ese espacio de nombres cuenta con una lista de objetos variable; según el tipo de proyecto que se desarrolle aparecerán unos u otros. En una aplicación cliente, basada en formularios Windows, siempre tendremos a nuestra disposición el objeto My.Computer, que da acceso a los distintos dispositivos del ordenador: ratón, teclado, puertos de comunicación, registro de Windows, etc.

Mediante las propiedades y métodos de My.Computer.Network, objeto que representa el acceso a red desde el ordenador en que se ejecuta la aplicación, es posible comprobar si existe o no conexión, hacer ping a un servidor remoto, enviar y descargar archivos, etc. Incluso existe la posibilidad de que nuestro programa reciba una notificación cada vez que el estado de la conexión a la red cambie.

Con un fragmento de código como el siguiente, por ejemplo, se comprueba si existe o no conexión a la red y, a continuación, si el hipotético servidor remoto de la organización está disponible, en cuyo caso se envía un supuesto archivo con información para su posterior consolidación:

If My.Computer.Network.IsAvailable = True Then
  ' Hay conexión a la red
  If My.Computer.Network.Ping("http://central.fcharte.com") = True Then
    ' Hay conexión con el servidor
    My.Computer.Network.UploadFile("C:\Datos.xls", _
     "http://central.fcharte.com/reception","usuario","clave"
  End If
End If

Control de errores en SQL Server 2005

Cuando escribimos procedimientos almacenados, lógica de negocio que va a ejecutarse en el propio servidor de datos generalmente a demanda de las aplicaciones, el control de los posibles errores es un aspecto especialmente importante y delicado. Un fallo en un procedimiento almacenado se propagaría a todos los potenciales clientes, lo que puede significar dejar de atender a cientos o miles de usuarios.

En SQL Server el control de errores se lleva a cabo tradicionalmente mediante la consulta reiterada de la variable @@ERROR tras cada operación. Si dicha variable indica que la operación no ha tenido éxito el código puede proceder adecuadamente, por ejemplo revocando una transacción en lugar de confirmándola. En SQL Server 2005 existe una construcción de más alto nivel, similar a la de algunos lenguajes de programación, que permite controlar los errores sin tener que comprobar a cada paso la mencionada variable. Su sintaxis es la siguiente:

BEGIN TRY
  /* sentencias que deben ejecutarse */
  COMMIT TRANSACTION
END TRY
BEGIN CATCH
  /* Control del error */
END CATCH

En el bloque BEGIN CATCH/END CATCH pueden utilizarse funciones como XACT_STATE(), ERROR_NUMBER() y ERROR_STATE() para saber si había o no transacciones en curso y su estado, obtener el código y el estado de error a fin de proceder como mejor convenga.