Korsarios.net

Posiblemente uno de los puntos mas fuertes de la tecnología .NET sea las capacidades de Reflexivas que le permiten recolectar información de un assembly mediante la lectura de metadatos internos. Una de las funcionalidades donde mejor se aprovecha esta capacidad es a la hora de debuggear, y capturar Excepciones.
Cuando, en proceso de debbugeo capturamos una excepción, y analizamos las propiedades que nos proporciona la clase Exception, para descubrir el objeto que produjo el error. Pero cuando exploramos el objeto Exception, encontramos innumerables mensajes y códigos de difícil comprensión. Por ello intentaremos en este post aclarar los campos con la información más relevante para analizar el error.

Analizando Exception encontramos los siguientes campos:

• Message: Te muestra un mensaje explicativo donde se describe el como y donde se produjo el error. Es quizás la propiedad mas útil para conocer el error que se ha producido.
• Source: Te muestra el nombre del assembly y el namespace en el que se inició la excepción. Esta propiedad es útil cuando trabajamos con varios asseblies referenciados en el proyecto, para conocer en cual de ellas se produjo el error.
• InnerException: Si la excepción que se ha lanzado es causada por otra excepción en un nivel inferior, te proporciona un objeto System.Exception de esta excepción primaria, para su análisis.
• StackTrace: StackTrace muestra los procedimientos estaban siendo ejecutados en el instante en el que la excepción fue lanzada. Esta propiedad te permite conocer el estado de la pila y ver así en que situación del sistema había otros procesos en ejecución.
• HResult: Este numero(pasado a Hexadecimal) representa 3 campos con información acerca del error. Un campo te indica el si el la excepción es informativa, una advertencia o un error. Otro campo te indica la zona del sistema donde se produjo el error. El tercer y ultimo valor representa un código único que representa al tipo de error producido.
• TargetSite: Si al producirse una excepción, no es posible saber que método la ha lanzado, esta propiedad saca de la StackTrace el ultimo método en ejecución en el instante antes de que se iniciara la excepción, y te lo muestra como causante de esta. Normalmente la información que te proporciona TargetSite coincide con la información que te proporciona ExceptionMethod, aunque puede ocurrir que no sea así cuando el error no lo haya producido el ultimo método ejecutado en la pila, sino algún hilo de ejecución simultaneo o un error externo a la aplicación.
• ExceptionMethod: Esta propiedad te proporciona información acerca del método que inicio la excepción. Esta propiedad te muestra la información del método, sus parámetros, el alcance, el namespace o el assemby al que pertenece, a través de la propiedad “System.Reflection.MethodInfo”. También te permite conocer es estado de este método en el momento de la ejecución, mostrándote el valor de los parámetros o el valor devuelto por este.

Se podría entrar más en profundidad y por ejemplo, analizar los bytes almacenados en los registros de memoria o en la pila de procesos, o las direcciones de los punteros, pero la complejidad de ese análisis es grande y con las herramientas ya comentadas para mi son mas que suficientes.

Bueno Korsarios, espero que os sea de utilidad esta pequeña ayuda. Larga Vida y Prosperidad.

Malas noticias amigos, una Web mas que no podremos consultar en Firefox. Hace poco la Junta de Andalucía ha actualizado el diseño de la Administración Publica y aunque han mejorado ampliamente el diseño han mermado su funcionalidad o al menos el numero de exploradores en el que funcionaba. El causante de tanto alboroto es este JavaScript que los autores han decidido incluir para dotar al buscador en cuestión de cierto dinamismo.

function quitarAvisos()
	{

        text_TIPOACCESOObli.style.visibility = "hidden";

        textoAvisoForm.style.visibility = "hidden";
	}

function Validar()
	{
	var resultado = true;
	// Mensajes de error no visibles por defecto
       quitarAvisos();

        if (document.formSel.parfTIPOACCESO.value=="-1")	{
            text_TIPOACCESOObli.style.visibility = "visible";
            resultado = false;
            }

	if (!resultado)
		textoAvisoForm.style.visibility = "visible"; 

	if (resultado==true) document.formSel.cf.value=0;

	return resultado;		

	}

Lo cierto es que este código cuyo único propósito es mostrarnos unos avisos si hemos dejado algún campo sin marcar y ahorrarnos el envió del formulario si así fuera no es interpretado por Firefox. Pero aun así en un alarde de buenas intenciones el navegador de Mozilla hace el submit y envía el formulario. Entonces ¿Cuál es el problema? El problema es que los autores han incluido este atributo en el formulario:

<input value='1' name='cf' type='hidden'>

El cual puede encontrarse en dos valores 0 si el contenido que se envía es correcto y 1 si no lo fuera. Por defecto esta en 1 así que el servidor devuelve la petición porque Firefox al no entender el JavaScript no es capaz de cambiar este valor. Alguien mas malicioso que yo podría pensar que tantas molestias para asegurarse en local de que lo que se envía al servidor es correcto seria un indicio de que en el servidor no se lleva a cabo ningún tipo de comprobación. Malas noticias de nuevo en el servidor se comprueba todo. ¿Entonces? Pues entonces parece que no quieren que los que tengan Firefox consulten el buscador porque podrían haberse limitado a usar el JavaScript para mostrar y ocultar las capas que contienen el mensaje de error y delegar la comprobación al servidor como ya esta hecho. En fin… ¿vosotros que pensáis? leed y propagad Korsarios