ReflectPropertyDescriptor.SetValue does not preserve stack trace - by GoldenCrystal

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 740318 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 5/3/2012 1:50:42 AM
Access Restriction Public


If an exception is raised while updating a data bound property of a windows forms control, it seems that System.ComponentModel.ReflectPropertyDescriptor will always catch the exception and eat its stack trace.

So we end up with unhelpful stack traces like this one:
   at System.ComponentModel.ReflectPropertyDescriptor.SetValue(Object component, Object value)
   at System.Windows.Forms.Binding.SetPropValue(Object value)
   at System.Windows.Forms.Binding.PushData(Boolean force)
   at System.Windows.Forms.Binding.UpdateIsBinding()
   at System.Windows.Forms.Binding.CheckBinding()
   at System.Windows.Forms.Binding.SetListManager(BindingManagerBase bindingManagerBase)

However, this does not reflect the real source of the exception, which can make debugging a real pain.
Sign in to post a comment.
Posted by andreas.laendle on 1/23/2013 at 1:51 AM
I really couldn't understand why this is closed as "won't fix" without giving any reason for this decision. I agree with GoldenCrystal that such a callstack is pretty useless and makes debugging quite hard. Maybe you should reconsider this issue since at least I couldn't find any reason why it's necessary (e.g. for security reasons) to truncate the callstack at the SetValue method. Also this isn't compliant with your own framework design guidelines - I'll guess a lot of developers would be thankful if you improve the behavior in future .net versions.

Best regards,
Posted by Microsoft on 5/3/2012 at 1:57 PM
Thank you for sharing your suggestion. Customer feedback is a critical part of a successful, impactful software product. Unfortunately another part is the reality of schedules and the need to prioritize investments according to the objectives of the product. We have evaluated your suggestion and at this point in the product's lifecycle, it does not meet the criteria to be addressed. This evaluation is carefully done and considers many aspects including the cost of the fix, implications of the change, and the number of reported instances of the issue.

Many customers have found it useful to discuss issues like this in the forums ( where Microsoft and other members of the community can recommend ways of achieving the behavior you are interested in.

Thank you,
The Windows Forms Product Team
Posted by MS-Moderator07 [Feedback Moderator] on 5/3/2012 at 2:33 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.