Extienda la excepción lanzada desde ASP.NET al llamar a un servicio web desde JQuery

Question

Estoy usando JQuery para cargar controles dinámicamente en un entorno de desarrollo ASP.NET usando JSON y WebServices. Dentro de esta solución tengo una capa de lógica empresarial que tiene un mecanismo de validación integrado (es decir, propiedades de validación y reglas comerciales similares a las de CSLA)

Al solicitar que un nuevo control se cargue dinámicamente usando JQuery y un servicio web ASP.NET , Me gustaría validar la entrada del control actual contra el mecanismo de validación de la lógica de negocios (es decir, la validación del lado del servidor) y notificar al usuario si hubo algún problema.

Me las arreglé para lograr esto, sin embargo, cuando la validación falla en el servicio web, me gustaría lanzar una excepción de cliente que contenga los id de campo de validación y los mensajes de error asociados.

En JQuery, pruebo para este tipo de excepción específico y me gustaría aplicar los mensajes de error dinámicamente a los controles enumerados en las propiedades del tipo de excepción. Aquí es donde entra mi problema. Aunque creé una excepción personalizada con propiedades personalizadas, la excepción que se pasa a JQuery en formato JSON desde WebService sigue siendo una excepción estándar sin ninguna de las propiedades adicionales enumeradas. Simplemente podría crear una cadena de valores con formato JSON en la propiedad de mensaje de la excepción, pero finalmente preferiría algo un poco más elegante. ¿Alguien sabe cómo se puede anular la excepción serializado creado por ASP.NET para situaciones como esta ...

gracias de antemano ...

G

Answer 1

me encontré con algo muy parecido Hace dos días, básicamente, no hay forma de que ASP.NET genere excepciones personalizadas. Esta es by design, ya que volver a un tipo específico de excepciones que

[...] exponer aplicación detalles/bugs a los clientes. podríamos hacer algo con excepción especial tipo que dejamos que pase a través, pero su demasiado tarde para esta versión [...]

You could always return different HTTP status codes, y que el navegador los manejan como excepciones personalizadas - por ejemplo, un error 500 significaría una cosa, otra 401, etc. Creo que la mejor solución es hacer que su método devuelva una cadena con la pila de excepción, no elegante, pero al menos así el cliente tiene todos los detalles de la excepción.

Dave Ward también tiene información sobre ASP.NET AJAX service errors.