Hello there,
I am creating a class in C# which eventually will be part of a library that other users can use. A user of this class has to set some properties and then use a public method to retrieve the results. What shall I do when a user calls the method without setting all the properties? Throw exception and expect the user to catch it?
Thanks
It might be better to create a constructor that takes the parameters, so that you are constructing an object instance that is in a usable state.
If you can't (or shouldn't) start your object with a known good state, then I would suggest throwing some kind of Exception up to the caller.
A good design makes it difficult to do the wrong thing. Perhaps in this case the API should take all the inputs as parameters to the method, which would probably then be static.
If the properties absolutely have to be set, then make them required parameters of the constructor and hide the default parameterless constructor.
If not all the properties need to be set, then you will need to rely on logging/exceptions to control the behavior.
Along with all the other options that have been mentioned you could have the properties set to default values. Then the user has to set them to something different if they don't want the default behavior. But really without knowing more about what your code is doing it's hard to say what the best option is.
Though I don't agree with your design of setting properties and then call the method, the best option seems to throw an exception since it's library. Exceptions are thrown to inform something unusual has happened - you can additionally pass a message with exception that mentions to assign the properties before calling the given method.
Even if there are 10 properties like you say, if they are required and it doesn't make sense to give them default values I would say put them all in the constructor.
If some of them can have reasonable default values then you can leave them out of the constructor and just set them to their defaults.
If none of the above are viable, for instance the object may need to be constructed before the values for those properties are known, then I would see if it makes sense for the required properties can be passed in as parameters to the method (e.g. it either doesn't have many parameters or isn't likely to be called many times, or if it truly is responding to its own internal state.)
Barring all of the above, an exception should be thrown. Also you mention "Throw exception and expect the user to catch it?" The purpose of throwing the exception shouldn't be because you expect the caller to catch it, you should expect them to make sure the property is set. Catching it should be a last resort when they cannot reasonably make sure the property is set and they don't care if your method fails as a result.
Can you use .NET 4? In that case the consumer can use named parameters if you want to keep it clear. So with properties you would have:
new Class
{
Prop1 = 123,
Prop2 = 123,
...
};
And with named parameters:
new Class(
param1: 123,
param2: 123,
...
);
Also, if you're using reference types you'll want to check for nulls either way. The difference is that with the constructor parameters you only check once, while with properties you'll have to check every time your method is called.