Reputation: 1781
I've got a piece of code which checks if an active directory domain 'exists'. I've put that in quotes because the domain:
The code I'm using is as follows:
var directoryEntry = new DirectoryEntry($"LDAP://{domainName}");
if(directoryEntry.Guid == null)
{
// What exception do I throw here?
}
I know it's recommended to use one of the standard exceptions wherever possible. But would a custom exception be more appropriate in this case? i.e. DomainUnreachableException
because I'm not sure if anything listed in this table is suitable.
Edit, just for a bit of context, the code I've shown is part of a method which sets up an object ready for further use. If certain conditions aren't met, the object is basically unusable. The conditions I have are as follows:
ConnectionFailureException
appears to be suitable here as it's what's thrown if you try to use the object.NullReferenceException
here since the indexer returns null if it cannot access or find the database.Upvotes: 2
Views: 106
Reputation: 7671
You can obtain the object, but it's state is not valid for in the context of current operation so the InvalidOperationException Class is appropriate according to it's description:
The exception that is thrown when a method call is invalid for the object's current state.
This exception is suitable to throw if you have already decided to carry out an operation, that is a 'decided' state for a method to run.
If your method which is doing a check for Guid == null
is supposed to describe an external resource or it's absence to make a decision, then you should not throw at all, but return a description object instead.
Upvotes: 2
Reputation: 14896
You should throw standard exceptions when they properly describe the error that occurred. ArgumentException
, ArgumentNullException
, InvalidOperationException
are very often a good choice.
In your case, you might consider throwing an ArgumentException
. It would be a good choice if the exception was thrown only when a domain doesn't exist. However, you will also throw it when the domain exists, but is unreachable. So the ArgumentException
will also be thrown if the domain name is correct, giving the client incorrect information.
It seems that throwing a custom exception is a good choice in this case. I don't know any standard exception that will perfectly fit your case.
And never throw Exception
or ApplicationException
. Clients will not be able to handle these exceptions correctly (catch(Exception)
will catch any exception thrown in the method, not only the one you throw).
Edit
As Kapol noticed ActiveDirectoryOperationException might be a good choice.
When throwing specialized exceptions like this, you have to consider what the clients know about your method. If they know it's an AD operation, you can throw an AD exception. If the AD is hidden behind some abstraction, throwing it will cause a leaky abstraction.
Upvotes: 1
Reputation: 6463
Creating a custom exception makes sense when the exception-catching code is aware of this custom exception, so that it can perform some actions specific to this exception type. If no special steps should be taken after catching your custom exception or a base class exception will be caught, then there is no need to create a new type. Just pass a meaningful message to the best-fitting exception type already defined in the FCL.
Maybe you could use ActiveDirectoryOperationException?
Upvotes: 1
Reputation: 2974
Make one custom exception similar to DriveNotFoundException A drive is unavailable or does not exist.
name it DomainNotFoundEcxeption inherited from Exception.
Upvotes: 0