Jake
Jake

Reputation: 1781

Is a custom exception suitable in this case?

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:

Upvotes: 2

Views: 106

Answers (4)

George Polevoy
George Polevoy

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

Jakub Lortz
Jakub Lortz

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

Kapol
Kapol

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

IamK
IamK

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

Related Questions