Is it an acceptable practice to Get a property, that involve parsing binary, that might throw an exception?

Question

I have a property that is loaded lazily, any time after the ctor is called.

It is possible that the binary that my property relies on is invalid. If invalid I might have to throw an exception.

Should I

Make the property a method, and be done with it.
Leave things as is.
Leave the property as-is, but add a method to validate the object, which will invoke the lazy parse, that might throw an exception.

Possibly related: [Is throwing an exception from a property bad form?](http://programmers.stackexchange.com/q/16646/64132) and even better, [Best practices: throwing exceptions from properties](http://stackoverflow.com/q/1488472/427192) (unless of course I've completely misread the question) — Dan Pichelman, Mar 10 '14 at 22:26

score 5 · Answer 1 · 2014-03-11T02:38:25.240

I would stick to throwing an unchecked exception.

The reason is it is not up to calling objects to validate your object. Furthermore, pulling the loading logic to a separate method means calling code must know to call method A before method B, and potentially method A can/should only be called once. This is a sequencing anti-pattern.

In this case, I prefer lazy loading which if done correctly ensures A. that loading is done only once, B. calling code does not need to know that methods in your class should be called in a specific order, potentially breaking if they do not.

Pseudocode:

public object getObject() {
  if (this.data == null) {
    loadObject()
  }
  return this.data
}

private void loadObject() {
  // Expensive loading logic...
}

Edit: I would like to clarify that getters/accessors should, generally, not throw anything. However, in this case, we are not dealing with a simple getter. I like to think of this not as "get some simple variable stored on the object" but "go get me some beer from the fridge, and if there are none left, throw a NullPointerException." After all if you are getting a value from some binary file or whatever, are you going to set it too? Probably not. So maybe another question is "should this be called a 'getter' to begin with?" which is a separate question.

From your casing I infer you're using Java. Does this advice apply to C# as well? I'm porting this code from Java and see many API approaches I would have done differently. — makerofthings7, Mar 10 '14 at 21:00
My advice is language-agnostic, and my code is generic "object-oriented in a C-like syntax." The API is different between the two languages, but the same OO concepts can be expressed in either. — , Mar 10 '14 at 21:03

score 0 · Answer 2 · answered Mar 10 '14 at 20:54

It depends on how much the user of the class knows about the file:

If they do not know it exists or its format, then having the property is sufficient as the users do not have any idea how to deal with the exception.
If the user of the class knows that this file exists, can specify the path, or can create this file, then having a method with clear exception throwing semantics would be better.
If you can get both types of users, then a property and method might have to be done.

Is it an acceptable practice to Get a property, that involve parsing binary, that might throw an exception?

2 Answers2