Etiquetas

,

ajax1

Si hemos realizados aplicaciones Asp.Net utilizando Ajax nos habrá pasado que los llamadas asincrónicas a métodos puede ser que produzcan algún error y este error se refleje a en la internas de usuario como un error de javascript, esto por supuesto presupone un riesgo de seguridad ya que estos errores podría estar mostrando información relevante de nuestra aplicación a terceros mal intencionados, de aquí la importancia de poder manejar estos errores y convertirlos en errores mas amigables para el usuario y lo mas importante ocultar información referente al funcionamiento de nuestra aplicación.

Para lograr manejar los errores que ocurren en las llamadas asincrónicas a métodos utilizadas por ajax a través de javascript nos tendremos que valer del evento ScriptManager.AsyncPostBackError este evento se produce cuando hay un error de página durante una devolución de datos asincrónica y pertenece al control ScriptManager .

Un ejemplo:

protected void ScriptManager1_AsyncPostBackError(object sender, AsyncPostBackErrorEventArgs e)

{

ScriptManager1.AsyncPostBackErrorMessage =”Mi mensaje al usuario aquí”;

}

En el ejemplo cambiamos el mensaje al usuario por uno mas amigable y ocultamos la información que podríamos estar cediendo a terceros, esto también podría se muy útil si queremos llevar un Log de este tipo de errores.

protected void ScriptManager1_AsyncPostBackError(object sender, AsyncPostBackErrorEventArgs e)

{

ScriptManager1.AsyncPostBackErrorMessage =”Mi mensaje al usuario aquí”;

MiClaseLog.Add(e.Exception);

}

En nuestro aspx solo tendríamos que configurar nuestro ScriptManager de la siguiente manera:

<asp:ScriptManager ID=”ScriptManager1″ runat=”server”

OnAsyncPostBackError=”ScriptManager1_AsyncPostBackError”>

</asp:ScriptManager>

Ahora bien si quisiéramos que no el navegador de ninguna manera mostrara un error de javasript sino que mostrar este error de una manera mas presentable al usuario a través de una capa div por ejemplo podríamos hacer uso de la clase Sys.WebForms.PageRequestManager que a través del método getInstance() no permite acceder a la funcionalidad de postback asincrónicos de la clase que esta en uso, además usando el método add_endRequest(EndRequestHandler) podemos añadir un manejador al evento endRequest que señala que la llamada asincrónica ha terminado.

Implementando todo esto en nuestro aspx:

<script type=”text/javascript”>

var divElem = ‘AlertDiv’;

var messageElem = ‘AlertMessage’;

var bodyId = ‘bodyId’;

Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequestHandler);

function ToggleAlertDiv(visString)

{

if (visString == ‘hidden’)

{

$get(bodyId).style.backgroundColor = ‘white’;

}

else

{

$get(bodyId).style.backgroundColor = ‘gray’;

}

var adiv = $get(divElem);

adiv.style.visibility = visString;

}

function ClearErrorState() {

$get(messageElem).innerHTML = ”;

ToggleAlertDiv(‘hidden’);

}

function EndRequestHandler(sender, args)

{

if (args.get_error() != undefined && args.get_error().httpStatusCode == ‘500’)

{

var errorMessage = args.get_error().message

args.set_errorHandled(true);

ToggleAlertDiv(‘visible’);

$get(messageElem).innerHTML = ‘”‘ +

errorMessage + ‘” ‘;

}

}

</script>

Mi div para mostrar el mensaje con el botón aceptar

<div id=”AlertDiv”>

<div id=”AlertMessage”>

</div>

<br />

<div id=”AlertButtons” >

<input id=”OKButton” value=”OK”

runat=”server” onclick=”ClearErrorState()” />

</div>

</div>

Quiero destacar la línea en la que aparece args.set_errorHandled(true); dentro del método EndRequestHandler, con esto indicamos que ya nosotros hemos hecho manejos del error y por lo tanto no se reflejara como error de javascritp en el navegador.