Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m trying to learn Code Contracts and get an idea of for what are they useful.
I have a WPF application, so a lot of code is bound to run exclusively on the UI thread. Quite a few utility classes expect to be called from the UI thread only.
Is it good idea so sprinkle these through my code? Why yes/not?
Contract.Requires(Thread.CurrentThread == Application.Current.Dispatcher.Thread);
Will the static checker be able to reliably check these?
Thanks for any input!
I think you are right to want to make these affinity checks. They are a great way to spot subtle bugs early but not something that can be checked statically using code contracts as mentions by Henk and decyclone.
I have a static class called
Ensurewith a methodEnsure.OnUiThread()that contains the exact same check as you mention. I mark this with[Conditional("DEBUG")]so as not to slow/bloat production code. Works nicely for me.