CODEWITHSUNDEEP
c#asp.net.netexceptionasp.net-web-api
tugberk
tugberk

Reputation: 58434

Throw or not throw the exception from the methods consumed by the ASP.NET Web API layer

Assume that I am building an ASP.NET Web API application and it has the following structure:

enter image description here

As you can see from the diagram, the ASP.NET Web API core will talk to domain service layer (e.g. MembershipService class which has methods such as GetUsers, CreateUser, etc.) and my service classes will talk to one or multiple repositories to handle the operations.

It's very obvious that a service operation (such as MembershipService.CreateUser method) would fail for several reasons (unmet conditions, an exception thrown by the repository, etc.) and this is the place where I have the doubts.

Do you think that service classes should handle exceptions and return some sort of result object such as the below one:

public class OperationResult {

    public OperationResult(bool isSuccess) : this(isSuccess) {
        IsSuccess = isSuccess;
    }

    public OperationResult(bool isSuccess, Exception exception) : this(isSuccess) {
        Exception = exception;
    }

    public bool IsSuccess { get; private set; }
    public Exception IsSuccess { get; private set; }
}

public class OperationResult<TEntity> : OperationResult {

    public OperationResult(bool isSuccess) 
        : base(isSuccess) { }

    public OperationResult(bool isSuccess, Exception exception) 
        : base(isSuccess, exception) { }

    public TEntity Entity { get; set; }
}

Or do you think that the service methods shouldn't abstract the exception like that and should throw the exception directly or indirectly (creating a new meaningful exception type specific to operation and put the thrown exception as its inner exception)?

Upvotes: 6

Views: 2457

Answers (3)

Darrel Miller
Darrel Miller

Reputation: 142014

When you are in-process, use exceptions.

Upvotes: 3

Mahdi
Mahdi

Reputation: 55

I don't see ANY point in avoiding exceptions. Exceptions are there for good reasons, mainly to be used! Just try to look at the big picture: you are trying to change Exception mechanism with the old fashion way of error checking. This way you'll lose all the merits of Exceptions (like separation of the error-handling and regular code, CallStack, ...) and gain nothing in return.

What I usually do in this situation is to catch the exception in service layer and rewrap it into a custom exception (with the reference to the original exception in the InnerException field).

Upvotes: 2

competent_tech
competent_tech

Reputation: 44921

Taking a page from Microsoft's book, the implementation of the Membership API throws exceptions rather than handling them and returning a result object, so I would consider this a best practice as long as you don't control both the client and the API.

In the case where you do control both the client and the API, it is my personal preference to return a result object or an error message. The reason for this is that I want to log capture detailed information about the source of actual exceptions, but I don't want an exception for everything that could go wrong, such as the password being incorrect.

In this case, a simple error message to the user will be more than sufficient. From real-world experience, recording exceptions to the event log or log file every time a validation error occurs is a major burden on operations personnel that are trying to determine whether or not there is an actual fault occurring or whether it is just a user's typo.

Upvotes: 1

Related Questions