jwcolby
jwcolby at colbyconsulting.com
Sat Jul 24 11:45:15 CDT 2010
Thanks Shamil. Interesting stuff all of this.
John W. Colby
www.ColbyConsulting.com
Shamil Salakhetdinov wrote:
> Hi John --
>
> Thank you for your questions.
>
> <<<
>> Dispose does all the clean-up for SqlCommand object instance...
> Is my code above correct then?
> Yes, it's more than correct IMO :) - I must say I almost never use that much
> clean-up coding in my .NET development:
>
> - I do never clean-up SqlCommand and SqlDataReader explicitly;
> - I do never close/clean-up SqlConnection;
> - I do use
>
> try {
> using (SqlConnection cnn = new SqlConnection(connectionString)
> {
> // SqlCommand and SqlDataReader etc. are in
> }
> }
> catch (SqlException ex)
> {
> // log exception
> throw ex;
> }
> catch (Exception ex)
> {
> // log exception
> throw ex;
> }
>
> Yes, I do use 'throw ex' not just 'throw' - and that my "approach" could be
> not so good
> (http://geekswithblogs.net/sdorman/archive/2007/08/20/Difference-between-quo
> tthrowquot-and-quotthrow-exquot-in-.NET.aspx ) but I do use it for several
> years in db intensive multi-user web apps - and it works well - no "memory
> leakage" - and I must say I have used my logging just a few times and it was
> informative enough to find and fix the bugs...
>
> "Excessive clean-up" is not needed in .NET as CLR's garbage collector does
> do good job for the code as above...
>
> <<<<<<
> If I log in the catch block do I really want to then throw
> the error? What is the calling procedure going to do with that?
> It seems logical to me to do the logging in the catch block
> and then NOT throw the error, but rather simply return
> a boolean false saying that the process failed.
> The calling procedure can then use
> the boolean to decide what to do. My understanding is that
> if I throw the error up to the caller
> then it ends up in its catch block, which may throw the error etc.
> I am good with handling the error close to the source but it just seems that
> implies NOT throwing
> the error on up.
> John, IMO there is no generic/common answer to your question - it depends on
> your app what to do with handled exception - "log and buble it up" or "log
> and suppress it" returning boolean failure code to the caller method:
>
> - logging and using Boolean is what is called "defensive" programming AFAIU
> - and it's "heavy good old professional style";
> - logging and throwing and exception up to the higest level caller is what
> is called "modern lightweight programming style" - in my opinion :) - and
> it's the most recommended nowadays AFAIS...
>
> Of course in the latter case of "modern lightweight programming style" there
> should be something(/some code) on the upper call stack levels to take care
> of the exception (to make some more logging and) to:
>
> - continue application execution gracefully;
> - quit the application...
>
> <<<
> And of course I need a reliable logger so that I can go see any errors.
> I do not use any besides some custom simple coding I outlined in this
> thread:
>
> - I just log into a simple text file;
> - I log into MS SQL, if that fails, log into text file, if that fails log
> into MS Windows application log.
>
> You can plan to use some existing logging frameworks but for the time beeing
> just write simple custom wrapper class, and then you can add advanced
> logging later...
>
> <<<
> And I have to make a living while I am learning,
> Yes, that's our destiny - the same story here, moreever...
>
> <<<
> and I am trying to teach a young fellow that works for me
> what little I know as well.
> If this young fellow is from a good IT college then they can teach you a lot
> (myself included) - I mean they usually know well all the modern
> approaches/methods of application programming - yes, more in theory than in
> practice but they often have a good overview we (seasoned developers) might
> lack because of the lack of time to study the theory - "fighting" everyday
> for living - just talk to the "kid programmer" - and you'll together will
> find your "proper" way of programming together...
>
> I suppose that for your case there are two proven sources:
>
> - ASP.NET 2.0 Website Programming: Problem - Design - Solution (Programmer
> to Programmer)
> (http://www.amazon.com/ASP-NET-2-0-Website-Programming-Programmer/dp/0764584
> 642) - it has real life sample web site/code solution with multi-layer
> "framework" - I did quote "framework" because it has just a few classes -
> you can "grab and use them" (sources are available free on WROX site)...
>
> - CSLA .NET for Windows (http://www.lhotka.net/cslanet/ ) - it's a huge
> framework - and I personally do not use it - I'd recommend to just get its
> sources (they are free) and to investigate the part of code belonging to the
> DataAccessLayer (DAL) - "suppress your temptation" (:)) to use this
> framework immediately - it would be very time consuming to learn it in
> details...
>
> I also suppose that nowadays combination of ADO.NET Entity Framework 4.0 +
> custom SPs mapping to your ADO.NET EF DataModel would be "what doctor
> ordered" but again it could take a lot of time to learn that "super modern"
> stuff - you can use simpler and time proven approaches referred above while
> learning/testing the latter (ADO.NET EF + custom SPs) in your spare time (if
> any)....
>
> Thank you.
>
> -- Shamil
>
> P.S: Disclaimer: All the above my opinions are coming from my own everyday
> .NET development experience, and are also gathered on Web, including
> Access-D/dba-VB and from technical books - they can be my own
> "misinterpretation or real world" sometimes - but they work well for me and
> for my customers :)
>
> -----Original Message-----
> From: dba-vb-bounces at databaseadvisors.com
> [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Saturday, July 24, 2010 1:26 PM
> To: Discussion concerning Visual Basic and related programming issues.
> Subject: Re: [dba-VB] c# so FINALLY ?
>
> Shamil,
>
> Thanks for your reply. C#, .Net and Visual Studio are very complex and I
> have so much to learn.
> And I have to make a living while I am learning, and I am trying to teach a
> young fellow that works
> for me what little I know as well.
>
> I need more information from you.
>
> I have two specific things I am trying to implement and make sure that I
> "cleanup" correctly. The
> first is that I have a ton of places in my code where I am using SQL Server
> records for table driven
> processes. As such I need to:
>
> 1) Work with data readers, looping through records.
> 2) Work with command objects doing .ExecuteNonQuery() to perform updates on
> flags.
>
> In both these scenarios I want to make sure that I open the connection, open
> the command object, do
> whatever the command object is going to do, close the connection, and
> cleanup the command object.
> And I want (am trying) to do this in a single place so that I get consistent
> object handling /
> cleanup. So, for example I use a static method of a class:
>
> public static bool ExecNonQuery(string strCnn, string strSQL)
> {
> SqlConnection mCnn = null;
> SqlCommand myCommand = null;
> try
> {
> mCnn = new SqlConnection(strCnn);
> mCnn.Open();
> myCommand = new SqlCommand(strSQL, mCnn);
> myCommand.ExecuteNonQuery();
> }
> catch (SqlException)
> {
> throw;
> }
> catch (Exception)
> {
> throw;
> }
> finally
> {
> if (myCommand != null)
> {
> myCommand.Dispose();
> myCommand = null;
> }
> if (mCnn != null)
> {
> mCnn.Close();
> }
> }
> return true;
> }
>
> > Dispose does all the clean-up for SqlCommand object instance...
>
> Is my code above correct then?
>
> > It doesn't make sense to have any SUCCESS/FAILURE return values from this
> method as it has throw
> calls inside of catch blocks
>
> OK. So if the .ExecuteNonQuery fails to work, the throw happens but...
>
> > Again follow KISS-principle: - log exceptions as close as possible to the
> point where they appeared;
>
> If I log in the catch block do I really want to then throw the error? What
> is the calling procedure
> going to do with that?
>
> It seems logical to me to do the logging in the catch block and then NOT
> throw the error, but rather
> simply return a boolean false saying that the process failed. The calling
> procedure can then use
> the boolean to decide what to do. My understanding is that if I throw the
> error up to the caller
> then it ends up in its catch block, which may throw the error etc.
>
> I am good with handling the error close to the source but it just seems that
> implies NOT throwing
> the error on up.
>
> And of course I need a reliable logger so that I can go see any errors.
>
> John W. Colby
> www.ColbyConsulting.com
>
>
>
> _______________________________________________
> dba-VB mailing list
> dba-VB at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-vb
> http://www.databaseadvisors.com
>
>