Reputation: 67213
I have an application, which resolves DNS hostnames to IP in one of its methods Question is, if the method which does this resolve is passed a null, what is the best thing to do? There are a few choices:
-Throw ArgumentNullException (programming errors should not be caught, except at the top, global error handler).
-Return another hostname (e.g. if a method accepts a person's name as a parameter, and that parameter is null, I could return "person" instead). If this is not possible, ie there is only one host in the network for which I can provide a hostname for, then it would make sense to throw an exception. Perhaps better than using another hostname, which may annoy the end user.
What is better?
Thanks
Upvotes: 2
Views: 80
Reputation: 81149
The right approach is to use the "trier/doer" pattern: have a "trier" method which will return what might or might not be a valid address (in such a way that the caller can tell whether the address is valid), and a "doer" method which will either return a valid address or throw an exception if it can't. Code which is prepared to deal with an inability to get a valid address should use the trier method; code which is not prepared for that possibility should use a "doer" method. The trier/doer pattern is often implemented by having both the trier and doer methods wrap a third method, which includes a parameter indicating what to do in case of failure.
Upvotes: 0
Reputation: 993015
A third option might be to return a corresponding null IP address. This allows the caller to make the decision about what to do based on the return value. (Presumably, you already return some kind of null IP address for hostnames that do not have a corresponding address.)
Upvotes: 0
Reputation: 41236
In one app I've worked on the situation was like so:
Is the Hostname available? Yes, return that.
If the Host IP Address available? Yes, return that.
Else return `Unknown`.
In your situation though (and from the sounds of it, using .NET), if it's a fatal error for your application, it should just throw whatever error it got up the stack. If there is something you actually want to return in lieu of the host name, then it would be right to catch the exception and recover.
A 'boneheaded' exception, where someone passed in null, should be throw up the stack and not caught, because that is indicative or bad code and should be fixed when found.
Upvotes: 0
Reputation: 27486
I would say throw the exception and then have the top-level handler print an appropriate message to the user. Returning an alternate hostname is probably not what most users would expect.
Upvotes: 0
Reputation: 12730
Think of it like a service. The folks who are consuming the service will want to know if there's garbage values being passed in so that it can be handled quickly and appropriately. Otherwise you'll get garbage out and not even know that anything was wrong.
Thus: throw the exception.
Upvotes: 1
Reputation: 37506
Throw the exception. Your method should never return a seemingly valid value in a situation where it receives input that you consider unacceptable. It should either return null or throw an exception (the better route). The reason for this is even if you come up with some "error code string," someone will not read your documentation or you will forget later and bang your head against the wall wondering why it's not failing when it should be failing.
Upvotes: 3