Possible to access business object/exception before it leave the server

Possible to access business object/exception before it leave the server

Old forum URL: forums.lhotka.net/forums/t/8254.aspx


espenrl posted on Friday, January 01, 2010

Hello,

This is my first post in this forum. I want to say many thanks to all behind CSLA. It is a fantastic product you are making.

Now: I want to log DataPortalExceptions server side, swallow them, and return a more generic exception to the user saying the problem is logged and will be looked into. I think it's good security not to return error information that can reveal secrets of the datalayer.

My question is: Is there a central point I can do this? Something corresponding to the IAuthorizeDataPortal, but giving access to the business object/exception before it leaves the server?

My alternative so far is to wrap every dataportal method with exception handling. This works fine, but is not optimal with respect to code duplication.

JonnyBee replied on Saturday, January 02, 2010

Hi Espen,

I'd recommend you to buy the Core series of vide from Rocky. The DataPortal video covers a lot of this.

For my own applications this type of logging/nessage to user is handled in the client. For pure logging purposes you should create your own intermediate base class and implement logging there. Go to CslaContrib.codeplex.com and look at the MyCsla project that shows these hooks.

Remember - the data access methods are not like an ordinary WebService (where the WS should be considered its own application with authentication/logging/exception handling) but rather a part of your application. You should decide what type of info you want to display to the user in the client.

I would however like to have the same function in DataPortal mostly for:
* transform NonSerializable exceptions to my own exception (could be done standard in Csla)
* transform from an NonStandard .Net Exception to my own exception when the exception occurs in a 3rd party assembly that does not exist on the client side (like TdException from the TeraData .Net driver and MqException from MQ assemblies).

The general recommendation is to have no general exception handling in your DAL and let Csla return the Exception wrapped in a DataPortal exception to the UI layer.

espenrl replied on Thursday, January 07, 2010

The idea of making my own subclasses is guite good. But it would have been even nicer too have a solution like this:

interface IDataPortalResultHandler
{
DataPortalResult HandleResult(DataPortalResult o)
}

class Logger : IDataPortalResultHandler
{
DataPortalResult HandleResult(DataPortalResult object)
{
// alter object and return it
Log(object.Error)
object.Error = new GenericException();
return object;
}
}

...and then configure the dataportal to actually use the class to handle all DataPortalResults.

What do people think of this? Is it only me that wishes this functionality?

Curelom replied on Friday, January 08, 2010

You can use Enterprise Library from Microsoft patterns and practices. It just requires a couple lines of code in the application and some configuration. You can log all or specific errors to a number of datastores such as a database, file, event, email, etc..

http://msdn.microsoft.com/en-us/library/cc467894.aspx

RockfordLhotka replied on Friday, January 08, 2010

The ability to alter the business exception before it leaves the server is now in the wish list and may be a 4.0 feature.

espenrl replied on Friday, January 08, 2010

Thanks Rockford!

I did implement the compression feature in a project today. I noticed I could alter the ConvertResponse in the custom WcfPortal to do what I wish in this post. From there I have full control over the exceptions returned by the server.

This is just theory, but I don't see why it should not work. I will test this when I have time.

RockfordLhotka replied on Sunday, January 10, 2010

If you are very careful this could work - but only with the Silverlight data portal, because the .NET data portal doesn't have these hooks.

In general I don't think it is a good general solution, because it requires too much intricate knowledge of how the data portal works and how it expects the data to flow.

And if I encourage people to play with the pipeline data at that level, then I can't change the data portal over time without breaking everyone who writes code in there. The abstraction level is too low, making fragility too high.

But I suspect you can make it work if you try.

Copyright (c) Marimer LLC