Exceptions

[GD Deepz]

Hi all, how is everyone handling exceptions. I am trying to implement a good exception handling i.e layer conformed exceptions-- meaning each layer will handle a specific exception at a layer and escalate it to the client. For ex:

1. class Data
public String [] readRecord(long recNo) throws RNF -- GIVEN BY SUN

2. class DataAdapter
public String [] readRecord(long recNo) throws RNF, RemoteException{
Data.readRecord(recNo);
}
3. class Remote(RMI)
public String [] readRecord(long recNo) throws RemoteException{
DataAdapter.readRecord(recNo);
}
4. Client
Client.readRecord(2);

public String [] readRecord(long recNo) throws ClientControllerException {
try{ Remote.readRecord(recNo)
}catch (RNF r)
throw new ClientControllerException(r)
}catch (RemoteException re){
throw new ClientControllerException(re)
}

2 will "only" "catch" rnf and throw new RNF()
3 will "only" catch RemoteException and throw new RemoteException()
4 Client will catch the RNF exceptions and RemoteExceptions thrown in
2 and 3, warp those excpetions in a customized ClientControllerException--> not sure how do this yet, getting errors when I am wrapping the exceptions.

All will be checked exceptions and will be escalated to the client. Is this the proper approach by catching layer specific exceptions at a certain level and escating them to the client

[Kai Witte]

hello,

generally your approach is very good: Let methods throw those exceptions that make sense for the associated layer of abstraction, use checked exceptions for unavoidable exceptional situations.

Without further knowledge about your design I can't tell you in detail if the exceptions thrown by the methods you showed us are the right ones. The ClientControllerException looks a little strange at a first glance, though: By the name of the exception alone I can't imagine when it will occur. Besides it seems to me that RecordNotFoundException would still make sense at that layer of abstraction, because obviously (method name, "readRecord") at that layer the term "record" makes sense, and that it may not be found is a problem that makes sense on that layer, too. But it might be a good solution in the big picture of your design. For RemoteException on the other side I can very well imagine a design where there is an interface with readRecord that has nothing to do with networking directly, because it is the same for stand-alone-mode and client mode. There it would be good to throw an exception that makes sense for that layer, and RemoteException would not qualify for that.

In some cases it is really good to let an exception wander to the next element on the stack, even several times. Make sure you did that where it makes sense. RecordNotFoundException would be a typical candidate for this, but that again depends on your design.

2 will "only" "catch" rnf and throw new RNF()

That is not a good idea in most cases; just let it wander to the next element of the stack by itself. An situation where this can make sense is if the state of an object would be weird if the exception would just occur and interrupt you while changing the object, but even then a finally clause usually is the better solution.

I had B & S 2.3.2. I got a very bad score for the GUI and a very good one for the rest.

If you want to read more about good practice with exceptions I recommend "Effective Java". You have to read quite a lot of articles to get the knowledge that is destilled in one chapter of it.

Conan

[GD Deepz]

Thanks Conan, your feedback helps. Please take a look

"2 will "only" "catch" rnf and throw new RNF()"

why is this not a good idea? Is not keeping thrown expections layer specific. The adapter will catch a specific exceptions eventhough its throw clause will indicate "other" expections, but those "other" exceptions will be caught in another layer. For example, the remote RMI class should only catch RemoteExcetions, throw it and let the client actually catch it.

The client will catch all exceptions thrown in the layers below.

[Kai Witte]

hello,

Originally posted by GD Deepz:

"2 will "only" "catch" rnf and throw new RNF()"

why is this not a good idea? Is not keeping thrown expections layer specific. The adapter will catch a specific exceptions eventhough its throw clause will indicate "other" expections, but those "other" exceptions will be caught in another layer. For example, the remote RMI class should only catch RemoteExcetions, throw it and let the client actually catch it.

The client will catch all exceptions thrown in the layers below.

other exceptions would be ok, but i assumed that with "rnf" you meant the same as "RNF", and that is not an other exception but the same!

So this is bad most of the time:

public String [] readRecord(long recNo) throws RNF {
    try {
        return dat.readRecord(recNo);
    } catch (RNF r) {
        throw new RNF(r.getMessage());
    }
}

better:

public String [] readRecord(long recNo) throws RNF {
    // may throw RNF
    return dat.readRecord(recNo);
}

Conan