Error logging on the server

Does anyone know a good way to log exceptions on the server? I'll have client errors that say "the server has encountered an internal error" but I don't know why. Maybe there's a way the remote dataportal can write the errors to a log file but I'm not sure where that code would go.

We use the ECL.

With the exception handling, you can use a logging handler for exceptions, which ends up utilizing the logging portion of the ECL. With the logging portion of the ECL you can use listeners, one of which is a database listener which will take logs (of errors in this case) and write them to the database. We built a custom listener which uses a CSLA object to remote over and write it to the database, if we want to support n-tier where the machine handling the exception isn't the server and/or doesn't have access to the database.

 

I still don't understand where the code goes. I actually use log4net but in this case I'd like the remote server to log errors to a file locally. The client side errors are handled seperately.

It seems like there would be some hook or place in CSLA where I could log all exceptions that happen on the server.

Well, we tend to just capture the errors on the client (and with ASP.Net if they are unhandled there's a place to handle them, I suspect there's a WinForms equivalent).

If you want to catch them on the server w/in the DataPortal, you could insert a method in *your* framework's business base - that class you insert between Csla.BusinessBase and any of your classes...

Upon an error in the dataportal, it looks to call this method on your object. You could place the code there.

            obj.CallMethodIfImplemented(
              "DataPortal_OnDataPortalException",
              eventArgs, ex);

Hope that's what you're asking

That's what I do.. override OnDataPortalException.  You can do this in something like MyCompanyBusinessBase, and have all your classes inherit that subclass.  Rocky recommends creating such a subclass even if initially it doesn't add any behavior at all, because someday you will.

One thing to watch is that if you're doign different logging on server vs. client you need to check ExecutionLocation.  But it works great. 

My exception handling actually builds up a message, drilling down to all InnerExceptions and emails the whole thing to me.  Very helpful to finding out where the exception is occuring.  If the email fails to send for some reason, my fallback is to log a message to the Windows Event Log.  This can be tricky to get going at first, because if you're remoting you'll need to manually add the Application Name to the registry so that your application can use that name (and you'll want to do this to distingish between your remoting application and other asp.net errors).

HTH
Andy