[How-to] Información de excepciones en ADO.NET Data Services

Por defecto, al crear un servicio ADO.NET Data Sevices, no tenemos información de errores y, si se lanza alguna excepción o hemos cometido algún fallo, obtendremos un mensaje con tan poca información como este:

Por lo que no tenemos ni idea de lo que está pasando con nuestro servicio. Realmente, nuestro error ha sido el siguiente:

No hemos introducido el nombre del EntitySet al que queremos asignarle la regla de acceso correspondiente y no hemos introducido el nombre de la operación de servicio a la que queremos asignarle los derechos correspondiente.

 

Bien, podemos obtener toda la información de las anomalías que se están produciendo añadiendo a nuestro servicio dos líneas de código:

El atributo ServiceBehavior lleva en el Framework .NET desde la versión 3.0 en la que se incluyó WCF y nos provee de la capacidad de especificar el comportamiento de la implementación del contrato. Con la propiedad booleana IncludeExceptionDetailInFaults podemos decidir si las excepciones no manejadas del servicio son devueltas como errores SOAP.

Este atributo puede decorar cualquier servicio WCF en general, aunque también podemos indicarlo en nuestro fichero de configuración de la siguiente manera:

<system.serviceModel>
    <services>
      <service name=»PlainConcepts.Server.PlainService» behaviorConfiguration=»Debug» />
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name=»Debug»>
          <serviceDebug includeExceptionDetailInFaults=»true»/>
        </behavior>
      </serviceBehaviors>
     </behaviors>
    <serviceHostingEnvironment aspNetCompatibilityEnabled=»true»/>
</system.serviceModel>

 

La otra línea que hemos incluido tiene que ver con el objeto de la clase DataServiceConfiguration (en versiones anteriores, de la interfaz IDataServiceConfiguration), que provee de la propiedad booleana UseVerboseErrors, a través de la cual podemos indicar a nuestro servicio que el comportamiento por defecto para todos los errores de sus respuestas sean detallados. La interfaz IDataServiceConfiguration se ha incluido desde el Framework .NET versión 3.5 SP1.

Bien, con estas modificaciones, ahora obtendremos el siguiente error para la misma configuración errónea de nuestro servicio:

The server encountered an error processing the request. The exception message is 'Exception has been thrown by the target of an invocation.'. See server logs for more details. The exception stack trace is:
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   at System.Data.Services.DataServiceConfiguration.InvokeStaticInitialization(Type type)
   at System.Data.Services.DataServiceConfiguration.Initialize(Type type)
   at System.Data.Services.DataService`1.CreateConfiguration(Type dataServiceType, IDataServiceMetadataProvider provider)
   at System.Data.Services.DataService`1.CreateProvider()
   at System.Data.Services.DataService`1.EnsureProviderAndConfigForRequest()
   at System.Data.Services.DataService`1.HandleRequest()
   at System.Data.Services.DataService`1.ProcessRequestForMessage(Stream messageBody)
   at SyncInvokeProcessRequestForMessage(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

Siempre recordar que este tipo de configuraciones son con el propósito de obtener más información de las excepciones que provoca nuestro servicio, por lo que es recomendable eliminar estas ayudas en entorno de producción.

Decir también que el comportamiento es equivalente cuando se consume el servicio a través de la librería de cliente System.Data.Services.Client o, incluso, cuando se incluye la referencia al servicio en el cliente para la generación del proxy, ya que si no tenemos esta ayuda, el servicio fallará y la información adicional que obtendremos será “The server encountered an error processing the request. See server logs for more details.”