Value Exception info as it was Gold

.NET / Fail / General

Everybody who is programming professionally knows that Exceptions carry information that can save you a lot of trouble, beginners and lamers ignore that simple fact. Counter productive exception hiding or re-throwing original exception while clearing the stack is very, very frustrating.

A couple of times I came across a practise of Re-Throwing exceptions – proposed by MS as a good practice. IMHO it’s very wrong, in some cases re-thrown Exception stack trace is cleared, thus original exception origin is overwritten. I’ve seen it in some examples and seen it in framework code. In result when you write buggy code, which is then called in framework code, your exceptions are caught and re-thrown but to find where your bug is located you will need help of a professional fore-teller, as it seems that it’s the framework code that screwed-up.

Following exception seem to originate form System.ComponentModel.ReflectPropertyDescriptor.SetValue(Object component, Object value), and this is what I’ve got after I’ve used my bindable user control the wrong way:

System.ArgumentNullException: Value cannot be null.
Parameter name: Path
at System.ComponentModel.ReflectPropertyDescriptor.SetValue(Object component, Object value)
at System.Web.UI.WebControls.ObjectDataSourceView.BuildDataObject(Type dataObjectType, IDictionary inputParameters)
at System.Web.UI.WebControls.ObjectDataSourceView.ExecuteInsert(IDictionary values)
at System.Web.UI.DataSourceView.Insert(IDictionary values, DataSourceViewOperationCallback callback)
at System.Web.UI.WebControls.DetailsView.HandleInsert(String commandArg, Boolean causesValidation) at System.Web.UI.WebControls.DetailsView.HandleEvent(EventArgs e, Boolean causesValidation, String validationGroup)
at System.Web.UI.WebControls.DetailsView.OnBubbleEvent(Object source, EventArgs e) at System.Web.UI.Control.RaiseBubbleEvent(Object source, EventArgs args)
at System.Web.UI.WebControls.DetailsViewRow.OnBubbleEvent(Object source, EventArgs e) at System.Web.UI.Control.RaiseBubbleEvent(Object source, EventArgs args)
at System.Web.UI.WebControls.Button.OnCommand(CommandEventArgs e)
at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
at System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
App_Web_kbsxsr1k, Version=0.0.0.0, Culture=neutral, PublicKeyToken=nulll

… 🙁 but it’s not. It’s my exception, thrown in the application code. If I did not took time to write an asserrtion, I would get an ordinary NullReferenceException and no fucking clue where did it originated! Pardon, my french, but at some point my blood pressure demand’s it.

Above is not curable, but is manageable, but this one is nasty:

Visual Studio lame excuse for an exception

Again, I know why VS does that, I probably can prepare a workaround. But do not know where to do it 🙁 ! People use chained exceptions, and log all stacktraces not just one!

When it comes to exceptions I follow these rules:

  • Rule 1: Try to catch exceptions as much as possible and re-throw higher level exceptions (meaning hiding the low level detailed and putting a message that is more related to the function of your code).
  • Rule 2: It is important not to loose the stack trace which contains important information. Use chained exceptions for that.
  • Rule 3: Always log the exception at the higher level (ie. where it is handled and not re-thrown).
  • Rule 4: Try to avoid catching Throwable or Exception and catch specific exceptions instead

… if only MS did the same way 🙁

Leave a Reply

Back to Top