답변 감사합니다

그런데 종료 커맨드를 수신한다는게 무슨 의미이신지요

while (isOpen)

        {

            try

            {

                    // Read from the InputStream

                    length = inStream.read(buffer);

                    byte[] trimed = new byte[length];

                    for (int i = 0; i < length; i++)

                        trimed[i] = buffer[i];

                    // Send the obtained bytes

                    // Length, Header

                    handlerBluetooth.obtainMessage(MyBluetooth.HANDLER_MESSAGE_RECV, length, id, trimed).sendToTarget();

            }

            catch (IOException e)

            {

                if (D)

                    Log.e(TAG, "disconnected", e);

                Message msg = new Message();

                msg.what = MyBluetooth.HANDLER_CONNECTION_LOST;

                handlerBluetooth.sendMessage(msg);

                break;

            }

        }

실제로 문제가 되는 코드인데 

 length = inStream.read(buffer);

에서 블로킹되어 있는 상태에서 소켓을 닫으면 예외가 발생하는 것 같습니다.

딱히 블로킹되어 있는 상태에서 빠져나올 방법이 없는 것 같더군요

물론 IO에서 항상 예외처리를 해야 겠지요

하지만 예외란 말 그대로 예외적인 상황을 대비하는 것이지

로직상 당연히 예외를 발생하게 만드는 구조는 별로 좋은 구조같아 보이진 않습니다.

꼭 그렇지만은 않습니다..

왜냐면 실제로 의도적으로 예외를 발생시키는 경우도 있거든요..

예를 들어 DB를 검색했을때 관련 레코드를 찾지 못하는 그런 경우가 발생하면 사용자 정의로 만든 RecordNotFoundException 머 요런것을 만들어서 의도적으로 catch 문에 throw new RecordNotFoundException() 을 하는거죠..

그러면 그 Exception이 Strack 을 타고 계속 호출된데로 빠져나오면서 그에 따른 일관된 예외 처리를 할수 있습니다..

즉 번잡하게 if then else를 쓰는게 아니라 걍 exception 객체를 던짐으로써 특정한 상황이었을때 일관된 처리를 하게끔 하는 방법도 있습니다..

네, 일리는 있습니다

제 생각에는 말씀하신 경우는 관련 레코드가 있을 수도 있고 없을 수도 있으므로 예외가 항상 발생하는 것이라 할 수 없고,

따라서 코딩 스타일에 따라 말씀하신대로 처리할 수도 있겠죠

하지만 그... 제가 말한 샘플코드에서는

현재 상태(소켓 연결 상태?) 모르는 것이 아니고, 

사용자의 명시적(?) 입력에 의해 소켓을 닫는 경우에도 

항상 예외를 발생시키는 것이기에 분명히 좋은 로직은 아니라고 봅니다.

NIO 쪽을 알아보려 했지만 일반 소켓은 가능해도 블루투스 소켓은 쓸 수 없는 것 같더군요...ㅠㅠ