Best practices: throwing exceptions from properties

by

Microsoft has its recommendations on how to design properties at http://msdn.microsoft.com/en-us/library/ms229006.aspx

Essentially, they recommend that property getters be lightweight accessors that are always safe to call. They recommend redesigning getters to be methods if exceptions are something you need to throw. For setters they indicate that exceptions are an appropriate and acceptable error handling strategy.

For indexers, Microsoft indicates that it is acceptable for both getters and setters to throw exceptions. And in fact, many indexers in the .NET library do this. The most common exception being ArgumentOutOfRangeException.

There are some pretty good reasons why you don’t want to throw exceptions in property getters:

  • Because properties “appear” to be fields, it is not always apparent that they can throw a (by-design) exception; whereas with methods, programmers are trained to expect and investigate whether exceptions are an expected consequence of invoking the method.
  • Getters are used by a lot of .NET infrastructure, like serializers and databinding (in WinForms and WPF for example) – dealing with exceptions in such contexts can rapidly become problematic.
  • Property getters are automatically evaluated by debuggers when you watch or inspect an object. An exception here can be confusing and slow down your debugging efforts. It’s also undesirable to perform other expensive operations in properties (like accessing a database) for the same reasons.
  • Properties are often used in a chaining convention: obj.PropA.AnotherProp.YetAnother – with this kind of syntax it becomes problematic to decide where to inject exception catch statements.

As a side note, one should be aware that just because a property is not designed to throw an exception, that doesn’t mean it won’t; it could easily be calling code that does. Even the simple act of allocating a new object (like a string) could result in exceptions. You should always write your code defensively and expect exceptions from anything you invoke.

More Related Contents:

  1. How to get the list of properties of a class?
  2. Set object property using reflection
  3. Is there a difference between “throw” and “throw ex”?
  4. WPF global exception handler [duplicate]
  5. What are Automatic Properties in C# and what is their purpose?
  6. Exception messages in English?
  7. How using try catch for exception handling is best practice
  8. How to rethrow InnerException without losing stack trace in C#?
  9. TAP global exception handler
  10. Puzzling Enumerable.Cast InvalidCastException
  11. Raise an event whenever a property’s value changed?
  12. Can you catch a native exception in C# code?
  13. Why is it impossible to override a getter-only property and add a setter? [closed]
  14. Avoiding null reference exceptions
  15. Is the C# compiler smart enough to optimize this code?
  16. User Activity Logging, Telemetry (and Variables in Global Exception Handlers)
  17. InvalidProgramException / Common Language Runtime detected an invalid program
  18. How to prevent an exception in a background thread from terminating an application?
  19. How to serialize an Exception object in C#?
  20. More Elegant Exception Handling Than Multiple Catch Blocks? [duplicate]
  21. ArgumentOutOfRangeException on initialized List
  22. How can I handle forms authentication timeout exceptions in ASP.NET?
  23. Checking for null before ToString()
  24. Thread Safe Properties in C#
  25. How do I determine the HResult for a System.IO.IOException?
  26. Catch Application Exceptions in a Windows Forms Application
  27. Properties.Settings.Default.Save(); -> Where is that file
  28. C# 3.0 Auto-Properties – Is it possible to add custom behaviour?
  29. Which types of exception not to catch?
  30. Dynamically changing Textbox’s AutoComplete List causes AccessViolationException, any advice?

Leave a Comment