{"id":503,"date":"2007-07-02T18:33:00","date_gmt":"2007-07-02T18:33:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/andrewarnottms\/2007\/07\/02\/how-to-not-write-an-especially-precarious-app-on-net-compact-framework\/"},"modified":"2019-04-03T22:50:51","modified_gmt":"2019-04-04T05:50:51","slug":"how-to-not-write-an-especially-precarious-app-on-net-compact-framework","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/premier-developer\/how-to-not-write-an-especially-precarious-app-on-net-compact-framework\/","title":{"rendered":"How to (not) write an especially precarious app on .NET (Compact Framework)"},"content":{"rendered":"

As the .NET Compact Framework developers work to add features, fix bugs, and refactor code, we often have to determine whether a given change could break existing customer code.  The ideal is that NetCF 3.5 will run all apps that ran on NetCF 2.0 and 1.0.  We run hundreds of apps and many, many tests before shipping each product to check backward compatibility.  The .NET Framework (both desktop and CF) makes heavy use of internal classes to allow us the freedom to change the internals of the framework without breaking customer code.  But there are still ways that customers can write apps that may break on future versions.<\/P>\n

Compare on exception text<\/H3>\n

Some exception types are very general and don’t tell you much about the error.  One of these is InvalidOperationException, which can be thrown for a wide variety of reasons for many classes in our BCLs.  Developers usually look at the Exception.Message property to get an idea of what went wrong.  This is by design.  What is not<\/EM> by design is for developers to write code in their apps that looks at the Message property and makes code path decisions based on it.  Here is an example: (highly contrived, admittedly)<\/P>

    class<\/SPAN> Program {\n        static<\/SPAN> void<\/SPAN> Main(string<\/SPAN>[] args) {\n            try<\/SPAN> {\n                XmlSerializer serializer = new<\/SPAN> XmlSerializer(typeof<\/SPAN>(MailAddress));\n            } catch<\/SPAN> (InvalidOperationException ex) {\n                if<\/SPAN> (ex.Message == “System.Net.Mail.MailAddress cannot be serialized because it does not have a parameterless constructor.”<\/SPAN>) {\n                    \/\/ Print message to user saying he chose a bad type to serialize<\/SPAN>\n                }\n            }\n            \/\/ Success!<\/SPAN>\n        }\n    }<\/p>\n
<\/PRE>\n
This can break in at least two instances: <\/P>\n
    \n
  1. The text in Exception.Message is localized to the computer running your app, so this code will break if it was run on, say a Spanish computer for example. \n
  2. A subsequent version of .NET Framework may change the Exception.Message text to be more descriptive, accurate or whatever.  <\/LI><\/OL>\n
    Either one of these likely cases may cause your code path to take a wrong turn (in this case to assume success).  Instead, you should write code that can analyze exceptions based primarily on exception type and\/or error code (enumerable or integer) where available.<\/P>\n
    Note: It is generally ok to display the Exception.Message to a user of an app in the form of a MessageBox or a log file (there are security considerations in doing this, however) and let the user choose how to proceed.<\/P>\n
    Compare on Exception type<\/H3>\n
    Another bad way of doing exception handling is to do absolute equality checking on exception types.  Here’s another bad (and contrived) example:<\/P>
        class<\/SPAN> Program {\n        static<\/SPAN> void<\/SPAN> ThrowBadArgument(int<\/SPAN> positiveValue) {\n            if<\/SPAN> (positiveValue <= 0)\n                throw<\/SPAN> new<\/SPAN> ArgumentException(“Must be positive”<\/SPAN>, “positiveValue”<\/SPAN>);\n        }\n        static<\/SPAN> void<\/SPAN> Main(string<\/SPAN>[] args) {\n            try<\/SPAN> {\n                ThrowBadArgument(-5);\n            } catch<\/SPAN> (Exception ex) {\n                if<\/SPAN> (ex.GetType() == typeof<\/SPAN>(ArgumentException)) {\n                    \/\/ Oops, the user provided a non-positive number!<\/SPAN>\n                }\n            }\n        }\n    }\n<\/PRE>\n
    Now suppose that the developer (or vendor) supplying you with your ThrowBadArgument method decided it was more appropriate to throw an ArgumentOutOfRange exception.  This would break your code and again cause your program to inappropriately assume success.<\/P>\n
    Here is a corrected example:<\/P>
        class<\/SPAN> Program {\n        static<\/SPAN> void<\/SPAN> ThrowBadArgument(int<\/SPAN> positiveValue) {\n            if<\/SPAN> (positiveValue <= 0)\n                throw<\/SPAN> new<\/SPAN> ArgumentOutOfRangeException(“Must be positive”<\/SPAN>, “positiveValue”<\/SPAN>);\n        }\n        static<\/SPAN> void<\/SPAN> Main(string<\/SPAN>[] args) {\n            try<\/SPAN> {\n                ThrowBadArgument(-5);\n            } catch<\/SPAN> (ArgumentException ex) {\n                \/\/ Oops, the user provided a non-positive number!<\/SPAN>\n            }\n        }\n    }\n<\/PRE>\n
    Note in this latter example how the throwing method is using the derived class.  But catching the base class in this way allows us to catch either ArgumentException or ArgumentOutOfRangeException equally well.  <\/P>\n
    And if you need to check the exception type using an if statement (to check the type of Exception.InnerException for example) be sure to use the is<\/STRONG> keyword rather than Exception.GetType() == typeof(…).  For example:<\/P>
    \/\/ good example<\/SPAN>\nif<\/SPAN> (ex.InnerException is<\/SPAN> ArgumentException) {\n    \/\/ do stuff based on inner exception<\/SPAN>\n}\n\/\/ Another good example (albeit harder to read)<\/SPAN>\nif<\/SPAN> (typeof<\/SPAN>(ArgumentException).IsInstanceOfType(ex.InnerException)) {\n}<\/p>\n
    \/\/ BAD example<\/SPAN>\nif<\/SPAN> (ex.InnerException.GetType() == typeof<\/SPAN>(ArgumentException)) {\n    \/\/ do stuff based on inner exception<\/SPAN>\n}\n<\/PRE>\n
    Finding public methods using reflection and parameter names<\/H3>\n
    There’s no good way to do this.  You should only find methods based on the parameter types<\/EM>, not parameter names<\/EM>.  The reflection API makes it easy to do it right, and harder to do it wrong.  Here is an example on how to do it right, and wrong:<\/P>
        class<\/SPAN> Program {\n        static<\/SPAN> void<\/SPAN> Main(string<\/SPAN>[] args) {\n            \/\/ Good example<\/SPAN>\n            MethodInfo m = typeof<\/SPAN>(int<\/SPAN>).GetMethod(“ToString”<\/SPAN>, new<\/SPAN> Type[] { typeof<\/SPAN>(CultureInfo) });\n            Console.WriteLine(m.Invoke(3, new<\/SPAN> object<\/SPAN>[] { CultureInfo.CurrentCulture }));<\/p>\n
                \/\/ Bad example<\/SPAN>\n            foreach<\/SPAN> (MethodInfo method in<\/SPAN> typeof<\/SPAN>(int<\/SPAN>).GetMethods()) {\n                ParameterInfo[] parameters = method.GetParameters();\n                if<\/SPAN> (parameters.Length == 1 && parameters[0].Name == “provider”<\/SPAN>) {\n                    m = method;\n                    break<\/SPAN>;\n                }\n            }\n            Console.WriteLine(m.Invoke(3, new<\/SPAN> object<\/SPAN>[] { CultureInfo.CurrentCulture }));\n        }\n    }\n<\/PRE>\n
    You should not take a dependency on parameter names of methods you call.  The .NET compilers take care of this for you, but if you go around them by using reflection and use parameter names rather than parameter types to find the method overload you want, you’re asking to be broken if those method parameter names ever change (and they can!)<\/P>\n
    Finding internal-only methods or types using reflection<\/H3>\n
    Again, there is no right way to do this.  Getting into the internals of a library by using reflection requires full trust and means you’re just asking for your app to break in the next version of the library when those internals get changed.<\/P>\n
    In conclusion…<\/H3>\n
    If you follow these tips, your apps will be more likely to perform well on current and future versions of the .NET Framework, on your own as well as your customers’ locales.<\/P><\/p>\n","protected":false},"excerpt":{"rendered":"
    As the .NET Compact Framework developers work to add features, fix bugs, and refactor code, we often have to determine whether a given change could break existing customer code.  The ideal is that NetCF 3.5 will run all apps that ran on NetCF 2.0 and 1.0.  We run hundreds of apps and many, many tests […]<\/p>\n","protected":false},"author":2685,"featured_media":37840,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[106,4617,3918],"class_list":["post-503","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-permierdev","tag-net","tag-andarno","tag-netcf"],"acf":[],"blog_post_summary":"
    As the .NET Compact Framework developers work to add features, fix bugs, and refactor code, we often have to determine whether a given change could break existing customer code.  The ideal is that NetCF 3.5 will run all apps that ran on NetCF 2.0 and 1.0.  We run hundreds of apps and many, many tests […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts\/503","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/users\/2685"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/comments?post=503"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts\/503\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/media\/37840"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/media?parent=503"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/categories?post=503"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/tags?post=503"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}