A couple of questions regarding Exception handeling.

["Trustin Lee (이희승)"]

Hi,

javadevmtl wrote:
> Hi using the latest 3.1.5 GA
> 
> Question 1: Is there a way to catch exceptions in one handler instead of
> various? Or control it better?
> 
> pipeline.addLast("timeout", new ReadTimeoutHandler(...)); <--- ReadTimeout
> gets caught in my handler
> pipeline.addLast("framer", new MyFrameDecoder(...));
> pipeline.addLast("stringdecoder", stringDecoder);
> pipeline.addLast("stringencoder", stringEncoder);
> pipeline.addLast("logs", loggingHandler);
> pipeline.addLast("threaded", executionHandler);
> pipeline.addLast("encoderdecoder", new MyEncoderDecoder(...)); <--
> Exceptions get caught in MyFrameDecoder
> pipeline.addLast("handler", new MyDHandler(...));

If you do not forward the ExceptionEvent to the next handler, the other
handlers will not get the exception.  However, it's better to silently
forward the event to the next handler if the exception is not interested
by the handler IMO.

> Question 2: Is it advisable to be able to write back to the channel in an
> exception? Or should you just always close the channel? And if you could how
> do you do so? Bassically on different types of exception I want to take
> appropriate action and maybe reply back to the client.

It depends on the severity of the exception.  If an IOException occurs
during socket I/O, Netty will close the connection automatically.
Otherwise you have a choice.  For example, if a client sends a wrong
data, you could close the connection.  If some server side error (DB
connection failure for example) occurs, you could send an error response
and keep the connection.

> Question 3: To avoid ClosedChannelException is it sufficient enough in my
> handler to do...
> 
> public void messageReceived(ChannelHandlerContext ctx, MessageEvent e)
> throws Exception {
> 		
> 	Channel ch = e.getChannel();
> 
> 	if(ch.isConnected)
> 	{
> 		ChannelFutur cf = ch.write(.....);
> 		cf.addListener(...CLOSE)
> 	}

There's no perfect way to avoid ClosedChannelException.  In the real
world, anyone can close the connection unexpectedly.  A client could be
shut down due to power outage or force closure and so one for example.
You have to live with it although you can do your best to minimize it.

> Question 4: Is there a way to control the ReadTimeoutException? Meaning...
> Each client which connects is expected to only send one and only one
> "message" to the server and wait for the server response. If the client has
> successfully sent the "message" I do not want the server to throw a
> ReadTimeoutException.
> 
> For instance client connects and sends request to the server. The server
> begins to process the request but takes a bit longer then the read time out
> value. Netty throws ReadTimeoutException (Which I catch and close the
> connection. Only want to do this if the client hasn't succesfully made a
> proper request). So now the client is disconnected because of this and never
> gets back the result. At this point also a ClosedSocketException is caught
> because obviously the server tried to write to a closed socket.
> 
> Maybe my understanding of ReadTimeout is wrong. The only reason why I even
> want to implement a ReadTimeout handler is because I want to make sure that
> the client doesn't fudge up the message sending and hangs for ever. But if
> the client has done everything correctly to not throw a ReadTimeoutException
> and to close the socket the moment the server is ready to send back the
> reply. Does it make sense?

ReadTimeoutHandler in Netty does not do what you want exactly.  It's
because it simply cannot determine if the state of the connection is
normal (full request received) or not (partial request received).

There are two ways to achieve what you want though:

1) Remove ReadTimeoutHandler as soon as you received the request.  You
could add it back when you finished sending a response.

2) Do not use ReadTimeoutHandler - implement timeout mechanism inside
your business logic handler.  You could refer to the source code of
ReadTimeoutHandler to do that.

HTH,
Trustin

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/