En cualquier curso de algoritmia o programación, bien en las universidades o en otro tipo de estudios se introduce la excepción como mecanismo básico de comunicación de errores en un entorno orientado a objetos. Sin embargo, quizá no sé explique o no se entienda por parte de los alumnos las implicaciones de usarlas correctamente en contraposición a otros métodos como la devolución de códigos de error.
Hay una serie de consecuencias importantes que podríamos resumir en:
- Unifican el método de comunicación de error. Deben ser utilizadas para comunicar errores en cualquier situación donde sea conveniente y no deben ser mezcladas con otro tipo de métodos, como los citados códigos de error. Un método de comunicación de errores siempre es mucho mejor que dos.
- Permiten controlar el error lejos del punto de fallo. Utilizando códigos de error este control siempre está cerca del fallo lo que aumenta las posibilidades de elección. La excepción puede ir “subiendo” en la pila de llamadas.
- El código se torna más robusto, el tratamiento de errores puede centralizarse o dividirse según decida el programador. Comunicar errores con códigos de error obliga, evidentemente, a utilizar sentencias condiciones (IF) para comprobar el éxito o fallo de la llamada. Además de aumentar la complejidad del código obliga a tratar el problema ahí mientras que con las excepciones podemos agrupar el tratamiento en el “catch” o en una parte superior de la pila de llamadas.
- Los códigos de error pueden ser ignorados con facilidad. Las excepciones sin embargo, rompen la ejecución normal del programa lo que hace imposible que sean ignoradas. Partiendo de que cuantos más errores sean detectados durante la fase de testing mejor será el código generado, queda claro que las excepciones facilitan esta detección.
Vamos, visto lo visto, cada vez que salte una excepción alégrate. En tu próxima versión no saltará 
Después de mucho tiempo de trabajo este lunes empezará a funcionar la nueva plataforma web de Domitienda.com. A nivel técnico comentar que se ha producido un cambio drástico en la arquitectura de todo el proceso de compra y facturación. En el blog podéis echar un vistazo a las funcionalidades que han acabado incluidas en la versión del día 11/01/09.
Sería interesante una visita ya que los descuentos promocionales del lanzamiento no tienen desperdicio:
Pese a ser un error bastante básico y que probablemente conozcáis, cuando se instalan sistemáticamente servidores con IIS es bastante posible que al aparecer este cause confusión y sorpresa. Buena señal supongo, estamos acostumbrados a hacer las cosas bien, o al menos como funcionan.
El síntoma es claro, se produce un error 404 (página o directorio no encontrado) al intentar ejecutar alguna página programada bajo el framework de .NET (extensión ASPX). El servidor tiene correctamente instaladas las versiones 1.1, 2.0, 3.0 y 3.5 del framework y además el filtro isapi está correctamente configurado.
Este error se produce ya que por algún motivo se ha instalado previamente el framework al IIS. Por lo tanto, pese a estar correctamente instalados ambos, el primero no se registra en el segundo. La solución es muy fácil, se debe ejecutar el siguiente archivo con el parámetro descrito:
- C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i
De este modo el framework 2.0 aparecerá correctamente en “Extensiones de servicio web” dentro del “Administrador de Internet Information Services (IIS)”. El ejecutable no solo realiza este paso si no que además establece los permisos oportunos dentro de la carpeta de temporales de ASP.NET.
Los Datasets forman parte de ADO.NET. Una librería de acceso a datos (no solo bases de datos relacionales) que se usa en el framework. Desde la versión 2.0 del framework tomaron si cabe más protagonismo debido al nuevo enfoque. Los Datasets se completaron con losTableAdapters. Clases concebidas para trabajar en conjunto y que exponen una serie de consultas de casi cualquier tipo que pueden ser diseñadas de manera muy cómoda a través del Visual Studio.
Los puntos fuertes son muchísimos, seguro que muchos fuera de mi conocimiento por falta de uso. Nos limitamos a utilizarlos a través de un Access o SQL Server pero van más allá. Queda ya para la historia su capacidad de integrar mediante un mismo modelo de programación el acceso a tantos tipos de datos distintos, además de permitirnos trabajar en nuestra aplicación directamente y de manera desconectada con nuestro origen de datos y siempre con variables debidamente tipadas. Esencial también y punto estrella para mí, el haber ofrecido de manera transparente y casi desconocida la parametrización de las consultas SQL evitando de esta manera infinidad de errores de Inyección SQL y comodidad extrema a la hora de pasar parámetros a la query (¿acaso alguien recuerda ya pasar una fecha al formato SQL correcto?).
Hago incapié en la seguridad y en la inyección SQL por la peligrosidad de este tipo de fallos de los que tan solo el programador se puede proteger (no hay política de seguridad que tu compañía de hosting te pueda ofrecer). Especialmente peligroso en motores potentes como SQL Server, Oracle, etc. que son capaces de ejecutar varios comandos en una misma sentencia simplemente separando por punto y coma. Un atacante hábil en una consulta mal parametrizada puede manipular la SQL completándola y añadiendo detrás la query más dañina que se le ocurra. No os costará nada encontrar muchísima literatura sobre el tema y algunos casos famosos.
Por desgracia, todas estas ventajas no son gratis o baratas desde el punto de vista de la eficiencia. Los datasets son objetos complejos que no solo representan tablas si no que además representan relaciones entre tablas. Esto que no deja de ser una ventaja en muchos escenarios supone que al realizar operaciones sobre el DataSet es necesario comprobar que las restricciones de integridad referencial se cumplen, con el coste computacional asociado.
He visto en muchos proyectos además, la manía de arrastrar tantas tablas como se pueda. En muchas ocasiones no hace más que provocar una caida de rendimiento en varios aspectos. En primer lugar en tiempo de ejecución. Un DataSet mal dimensionado es más lento al cargarsey además mucho más lento al operar con él. Además, en el trabajo del día a día del programador, manejar uno de estos a través del Visual Studio puede ser una odisea.
Desde un punto de vista transaccional, si no proponemos una estructura mejor cada operación con un TableAdapter inicializa una nueva conexión. Ello nos limita a la hora de utilizar transacciones, ya sea a nivel del motor de base de datos, o a un nivel superior utilizando clases como el TransactionScope del framework. Sobra decir que cada vez cuesta más encontrar aplicaciones donde se pueda pasar sin entender una infinidad de operaciones de manera atómica y más en un entorno tan distribuido como el actual.
Para terminar, desde el punto de vista de la interoperabilidad. Probablemente te interese esta parte si te estás iniciando en WCF o tecnologías similares. El hecho de que un Dataset se serialice automáticamente como XML no quiere decir que todas las aplicaciones sean capaz de interpretarlo. De hecho, será dificil de ver si la aplicación consumidora del servicio no es .NET. El schema del DataSet puede es complicado de procesar y en la mayoría de los casos tremendamente pesado en comparación con serializar una clase formada por tipos básicos o con una serialización personalizada.
Podeis ver el vídeo aquí:
http://www.infoq.com/presentations/shoup-ebay-architectural-principles
Siempre me ha atraido bastante la idea de la aplicación crítica en sectores como el bancario, asegurador, administración pública, etc. Esta exposición hará por lo tanto las delicias de aquellos interesados en conocer de primera mano la arquitectura de una verdadera 24×7. Las cifras asustan:
- 248.000.000 usuarios registrados
- 1 billón de fotografías
- 4,4 billones de llamadas al API
- 44 billones de sentencias SQL diarias
Todo ello descansado sobre patrones que aplican de manera constante:
- Partition everything
- Async everywhere
- Automate everything
- Remember everything fails
Especialmente impactante el hincapié que se hace sobre la tolerancia a fallos. Supone asumir de manera constante que cualquier operación puede fallar o cualquier recurso puede estar no disponible y tomar todas las medidas para que el sistema reaccione de la manera más inteligente posible.
Artículo muy interesante:
El gobierno español pasa de Linux en la educación … efectista cuanto menos. Textualmente, “un nuevo escándalo tecnológico en el seno de nuestro gobierno“. Tanto la noticia de esta publicación como de HispaLinux está llena de “perlas” a cada cual más gorda:
“Si se considerara un precio (rebajado) de 60 Euros por cada sistema operativo y de otros 52 Euros por cada licencia de Microsoft Office para Estudiantes, estaríamos hablando de un dispendio anual y recurrente en el tiempo de prácticamente 100 millones de Euros“.
Ese es el precio oficial, en efecto, de compra de licencia para un solo estudiante. ¿De verdad debemos suponer sin más información que es ese al precio que ha comprado el gobierno?. ¿Con qué información se hace esa afirmación?.
“A lo anterior habría que sumar otros costes de licencias, como el antivirus, indispensable para ese sistema operativo (e innecesario para Linux)”
Claro, ya que es el sistema operativo más seguro del mundo y sobre el cual no hay que establecer controles de seguridad. No es que esten mal informados, si no que faltan a la verdad. Hay divertidisimas estadísticas sobre el tanto porcentual de colaboradores de distribuciones concretas de Linux que tienen el nivel como para programar a niveles de abstracción cercanos al núcleo (un selecto grupo de ingenieros que cobra y muchísimo en empresas privadas) así como artículos sobre los distintos “toques” que se le ha dado a la industria del software libre para que siguiera las “buenas prácticas” que marca ahora mismo la ingeniería del software. Tareas relacionadas con la seguridad, como muchas otras. El hecho de que yo pueda ver el código no implica jamás que vaya a descubrir un bug.
“Por último, hay que tener en cuenta los sobreesfuerzos de mantenimiento que requiere Windows y que tendrían que sufragar las comunidades autónomas.”
De nuevo se falta a la verdad, y no es falta de información. De sobra es conocido que el software libre no es ni mucho menos gratuito y desde luego, los costes de mantenimiento de cualquier distribución requieren profesionales. Profesionales que por cierto, cobran igual que los que trabajan en entornos Windows. Que no es la primera vez que una administración pública (no española) da marcha atrás en un intento de implantación de Linux.
Así se pierde toda la razón y realmente es una lástima. Más que nada por que esgrimen argumentos que sí son realmente interesantes. Hay que preguntarse que dependencia tecnológica adquiere España al realizar una operación así o si es normal que en estos momentos de crisis no se saque esto a concurso. Pero desde luego, que Linux es más barato que Windows por el hecho de ser libre es como para reirse. Para bien o para mal, no es así.
Es curioso hasta que punto te puede llevar a la locura un pequeño error de nomenclatura.
Acabo de instalar con éxito un servicio de Windows que yo mismo he programado bajo C# (Framework 3.5). Por requerimientos concretos de este servicio en lugar de ejecutarse bajo el Local System Account (LSA) se debe ejecutar bajo una cuenta concreta de usuario de Windows (normal y corriente).
Las ordenes para instalar desinstalar el servicio son:
- C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\InstallUtil “c:\miservicio.exe”
- C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\InstallUtil /u “c:\miservicio.exe”
En caso de que hayamos especificado en nuestro ServiceProcessInstaller la propiedad “Account” como “User” se nos preguntará en el momento de la instalación acerca del usuario que “prestará” credenciales al servicio. Muy bien, importante, en caso de estar especificando un usuario local se escribe del siguiente modo:
“.\nombredeusuario”
Sin las comillas, por supuesto. Espero que a alguien le sirva de ayuda.
Interesante artículo:
http://duartes.org/gustavo/articles/Lock-Down-SQL-Server-2005.aspx
Extraido de:
Todo aquel que haya lidiado con DCOM o bien con WMI se habrá encontrado en alguna ocasión con algún problema de conectividad con una máquina remota. El problema es que los errores no son todo lo descriptivos que deberían, y es muy posible pasarse mucho tiempo buscando donde no hay nada. Esto no pretende ser una guía de conexión a máquinas remotas mediante DCOM (que es el mecanismo que subyace cuando atacamos también alguna clase WMI), pero quien sabe si le servirá de ayuda a alguien:
1) El firewall necesita una configuración especial para admitir accesos por los puertos que utilizan esta tecnología. Asegurate de que no te esté bloqueando nada la conexión.
2) Los errores no son siempre muy descriptivos. Asegurate de estar atacando a un ordenador existente y que esté en funcionamiento. Suena tonto, pero puedes perder mucho tiempo atacando una IP que no es y recibiendo un error de acceso denegado que te haga pensar en otros motivos.
3) Asegurate de que WMI está instalado. Ejecuta wbemtest para comprobarlo.
4) El usuario con el que accedes debería estar en el grupo de “Administradores” de la máquina objetivo. Asegurate por lo tanto de que tanto nombre, contraseña y privilegios están correctamente establecidos.
Mucho cuidado con los despistes, que pueden hacer perder mucho tiempo.
