Feature Req: Provide facility to supoprt detailed exception logging...

[GoogleCodeExporter]

Though we are looking to implement our own in the interim, it would be 
desirable for an 'official' exception handling/logging strategy to be 
provided.

The criteria for 'acceptable' for our immediate needs is that we'd like to 
be able to log the full connection string when either a connection failure 
occurs, or the connection and command when a command failure occurs.

Through investigating EntLib's DAAB we have seen that WMI events are 
published, but those wouldn't be scoped to the local thread I assume. Our 
logging strategy counts on catching an exception on a given thread, and 
then capturing information & bubbling that up the stack...  From the DAL 
perspective, we'd like to know various facts about the executing context 
such as connection (connection string, connection timeout) and whether 
we're in a transaction (transaction id) or distributed transaction as well 
as the command (the command type, timeout, name, parameters, etc)...  So 
the WMI eventing doesn't seem to do it for us. Rather we need to 
reference/capture that data in the code that has direct awareness of the 
objects in play...

Ideally, throwing a typed Exception with additional meta-data attached 
(not the connection/command objects themselves to prevent those objets 
leaving the scope of the DAL) would be nice...

I.e.

        public static IDataReader ExecuteReader(Database database, 
DbCommand dbCommand)
        {
            IDataReader results = null;
            try
            {
                results = database.ExecuteReader(dbCommand);
            }
            catch (Exception caughtException)
            {
                DalOperationException dalOperationException = new 
DalOperationException(caughtException);

                dalOperationException.ConnectionString = 
database.ConnectionString;
                dalOperationException.CommandName = dbCommand.CommandName;
                dalOperationException.CommandTimeout = 
dbCommand.CommandTimeout;
                dalOperationException.Parameters = new 
DalOperationParameterList();
                foreach(DbParameter dbParameter in dbCommand.Parameters)
                {
                   dalOperationException.Parameters.Add(dbParameter.Name, 
dbParameter.Value);
                }

                throw dalOperationException;
            }
            return results;
        }

-- Main concept here is that we are usign our own typed exception that is 
extended to have it's own represetnation of the meta-data about the 
connection/command...  Avoiding any actual reference to the real database 
objects...

I'd also be open to other suggestions of how to gain access to those 
contextual objects to make use of them in my own logging...

Original issue reported on code.google.com by bh...@yahoo.com on 12 Mar 2010 at 5:01

[GoogleCodeExporter]

I agree with the spirit of this suggestion, currently I trace a lof of this 
info to 
the console for debugging, but I don't permanently log it.  Of course I can see 
why 
that would be desirable.

I assume you are using MSSQL.  In the meantime, you may want to consider SQL 
Server's profiling and tracing.  

I have mixed feelings about logging a connection string and making that part of 
the 
template.  

It appears that this is something that can be accomplished with the EntLib's 
exception handling and logging blocks.  

I am updating this item to reflect that this is an enhancement request not a 
defect.

Original comment by rhet...@gmail.com on 12 Mar 2010 at 5:57

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

See also 285

Original comment by rhet...@gmail.com on 12 Mar 2010 at 6:19

[GoogleCodeExporter]

Our logging/exception handling is based on EntLib... It's just accessing the 
additional objects we want for very verbose level logging...  The connection 
string 
is important in our case due to building it dynamically to point to one of 50+ 
databases... Dont' ask why! <grin>

The key was to make the objects accessible to use as needed... right now, 
they're 
buried down in the DAL method and only when handling the exception in that 
operation's try/catch block...  The WMI eventing offered from EntLib DAAB 
doesn't 
offer what I need really...

As you saw my other new issues enterd, if the Utility.cs were extensible 
through 
overriden methods - then I could simply do as shown above keeping my special 
scenario out of the templates even... 

Original comment by bh...@yahoo.com on 12 Mar 2010 at 11:58

[GoogleCodeExporter]

Update: If I correctly understood something I read recently (which I just 
briefly 
glanced over) - I think the EntLib 5.x drop will be dropping the WMI events - 
which 
they didn't meet our needs at all - but noteworthy in regards to this issue...

Original comment by bh...@yahoo.com on 26 May 2010 at 1:50

[GoogleCodeExporter]

Hello,

We now support EntLib 5.0. There may be one or two small bugs we need to work 
out. Can you see if this is now resolved.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 21 Sep 2010 at 8:31

• Changed state: AwaitingInfo

[GoogleCodeExporter]

I'm not sure if I wasn't clear enough in my description of the needs - but 
supporting EntLib 5.0 isn't going to address the actual functional needs - it 
will answer the question as to whether they deprecated their WMI events or not 
though...

Original comment by bh...@questis.com on 21 Sep 2010 at 9:42