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

Question

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

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)?

Answer 1

When you are in-process, use exceptions.

Answer 2

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).