public class GroupRepository{
public Group findByName(String nameToLookFor) throws RepositoryException{
Group group;

try{
group groupDAO.findById(nameToLookFor);
} catch(SQLException e){
throw new RepositoryException(”Problems in the persistence…”, e);
}
return group;
}
}

The catch clause should log the exception?

} catch(SQLException e){
magicLogger.log(e)
throw new RepositoryException(”Problems in the persistence…”, e);
}

In the other hand there are times where the contract has to be broken and maybe that’s the kind of exception you are talking about. In that case bubbling up exceptions is fine but this is a broken contract, an uncommon situation often created by some failure in libraries or infrastructure your system uses.

If your client Layer has to handle and know all possible states of the server Layer then what’s the point in using Layers in the first place? Just group your objects into packages for some cohesion and let them talk. The reason client Layers should not know about how the underlying Layer is implemented is encapsulation. If you require the client to know all possible states of the server Layer you have high coupling between those, what’s generally something undesirable.

What Joel’s article says is that all abstractions leak and I agree with that. It does not say that we should encourage leaky abstractions; it says that we have to keep in our minds that it is not feasible to design an abstraction that won’t leak.

Now I’m not saying that you have to use Layers of even any high level abstractions, but once you decide to use that it is often good to maximise cohesion and minimise coupling. Grouping classes will give you the former but it is extremely hard to get the latter without a good API for your abstractions; and a good API has a good contract.

I’ll probably post examples in an upcoming post.

But what benefit does the client have knowing this? It seems like only a small amount of exceptions that might get thrown can be recovered from, so what can the client really do with this information?

“otherwise the client Layer would have to be able to deal with pretty much any possible situation that could happen”

I’d say this is always the case and client layers should be designed with this in mind. You even mentioned this with your reference to Joel’s leaky abstraction article.

I’m still not convinced there’s a significant benefit (maybe an example or reference would help). I understand your point with contracts, and it sounds nice, however I’m not convinced that you can often map every exception. With this in mind, it doesn’t seem practical to map some, knowing others might leak.

It is important because if you don’t map the original exception to something that is specified in the contract you just broke it. The contract defines what the client Layer must expect, all exceptions that can be thrown by a Layer should be defined in the contract.

Unless, of course, that you don’t use contracts between Layers. This is other topic but I’d recommend that you limit the number of possible exceptions anyway, otherwise the client Layer would have to be able to deal with pretty much any possible situation that could happen.

With respect to how the exceptions are handled and logged, why does it matter if I convert the internal exception to a contract exception?

I’ve always applied this rule on a case by case basis. I’ve seen other people suggest the ‘do it all the time’ approach, but I’ve never seen a good explanation as to why. I suspect this has more to do with code ownership and who’s consuming your code.

To me it seems more important to do this when exceptions move across subsystems or trust boundaries (e.g. exception shielding), and less important when moving across layers.

First of all, I would like to sorry my argumenting. But, I REALLY intrested in opinions about this topic.

1) This monitoring agent should’t be in the server? Or, maybe, you could worry when you map a server exception to a client exception that your client monitoring agent understand, or using an Exception’s Code.

2) This could be done with an Exception’s Code, in the Client Exception, instead a Server Exception. Something the HTTP code 502: Service Temporarily Overloaded. As java.sql.SQLException do: venderCode.

3) In this case I need to know the exactaly developer’s intend(what is he looking for?) to propouse a solution. But, if its a IDE debug, de developer always can put a breakpoint in the caller method

[],
AC

1) The client has some sort of monitoring / error reporting facility that sends any server exceptions to an admin via email, via a monitoring agent, or some other means.

2) The client may want to automatically respond to certain kinds of server-side exceptions. We have defined a sub-type of Exception called “Retriable” (say, when a server is overloaded, or has run out of DB connections). When an exception of this type is thrown, the client can check if the “cause” is of this type, and can retry the request without bothering the user.

3) A developer may be manually debugging or running a profiling tool that wants to have a look at the innards of the Exception. It would be a bummer if the act of inspecting the object causes it to blow up in your face.

@Phillip,
Right, that’s basically the point I was trying to make. Just a reminder that wrapping an Exception, while usually helpful, may actually be breaking encapsulation and causing problems in unexpected ways.

You should log the problem when it happened and throw an exception which your client can understand and handle. So the original exception has no meaning to the client, if he can’t handle it.

But if your client could handle, why don’t you throw the original exception instead some pseudo-abstraction?

And if your client can handle, doesn’t him doing more than he supossed to?

[],
AC

I don’t understand how multiple Layers would log the exception. The first one to receive it, the one who generates the exception or receives it from a subsystem or library (*not from other Layer*) will log that.

About logging in the last Layer, this is helpful as stack traces can give you the full path. Problem is that although it is very easy to know who is the first Layer it is hard to realise who is the last Layer. If a Layer knows that it is the last one it knows too much about the system, Layers should be atomic and independent.

@Tim

Besides the point raised by AC about not getting into the exception it feels like what you are having is the classic DTO/local objects problem. In this case “mapping” may mean detaching it from the server.