inner side

java.sql 
인터페이스 ResultSet

모든 슈퍼 인터페이스:

Wrapper

기존의 서브 인터페이스의 일람:

CachedRowSet , FilteredRowSet , JdbcRowSet , JoinRowSet , RowSet , SyncResolver , WebRowSet

<pre>public interface ResultSet

extends Wrapper

</pre>

데이타베이스의 결과 세트를 나타내는 데이터의 테이블로, 일반적으로, 데이타베이스에 조회하는 문장을 실행하는 것에 의해 생성됩니다.

ResultSet 객체는, 커서가 데이터의 현재의 행을 지시하도록(듯이) 유지합니다. 초기 상태에서는, 커서는 최초의 행의 선두에 배치됩니다. next 메소드에 의해, 커서는 다음의 행으로 이동합니다. next 는,ResultSet 객체에 그 이상행이 없는 경우에 false 를 돌려주므로,while 루프에 사용해 결과 세트를 반복 처리 할 수가 있습니다.  

디폴트의 ResultSet 객체는 갱신 불가로, 커서는 순서 방향에게만 나아갑니다. 따라서 이 객체는, 최초의 행으로부터 마지막 행으로 향해 1 회만 실행할 수 있습니다. 스크롤 또는 갱신, 혹은 그 양쪽 모두가 가능한 ResultSet 객체를 생성할 수 있습니다. con 가 유효한 Connection 객체인 다음의 코드 fragment는, 스크롤 가능해 외로 행해진 갱신을 반영하지 않는 결과 세트, 및 갱신 가능한 결과 세트의 작성 방법을 나타내고 있습니다. 다른 옵션에 대해서는,ResultSet 의 필드를 참조해 주세요.

Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_UPDATABLE);ResultSet rs = stmt.executeQuery("SELECT a, b FROM TABLE2");// rs will be scrollable, will not show changes made by others,// and will be updatable 

아래 java 도큐의 resultset 명세중.. '렬명' 이 alias(별칭) 과 동일한 의미.

getter 메소드에서는, JDBC 드라이버가 기본적인 데이터를 getter 메소드로 지정된 Java 형으로 변환해, 적절한 Java 의 값을 돌려줍니다. JDBC 스펙에는,ResultSet getter 메소드로 가능한 SQL 형으로부터 Java 형에의 매핑을 나타내는 테이블이 있습니다.  

getter 메소드에의 입력으로서 사용되는 렬명에서는, 대문자와 소문자는 구별되지 않습니다. 렬명으로 getter 메소드가 불려 가 복수의 열이 같은 이름을 가지는 경우는, 최초로 일치하는 열의 값이 돌려주어집니다. 렬명의 옵션은, 결과 세트로 생성되는 SQL 쿼리로 렬명이 사용되는 경우에 사용되도록(듯이) 설계되고 있습니다. 쿼리로 명시적으로 명명되지 않는 열의 경우에는, 열번호를 사용하는 것이 가장 좋은 방법입니다. 렬명을 사용하는 경우, 프로그래머는 목적의 열을 일의에 가리키는 것을 보증하도록 주의해 주세요. 이것은, SQL AS 절을 사용해 실현될 수 있습니다

포지션 1: 서버 클라이언트 개발 팀원 및 팀장 

업무내용 

:클라이언트 어플리케이션 개발팀

- GEM(Globally Executable MHP)/BD-J 표준에 따른 Java 어플리케이션 개발 
- Android 환경에서 동작하는 드리머 클라이언트 어플리케이션 개발  

업무내용 

- 서버 서비스 어플리케이션 개발팀원

- server-side application developer
- Cloud 기반 Server-side Java 어플리케이션 개발 
- 안정적이고 효율적으로 동작하는 서버 시스템 개발

주요 업무
1) Blu-ray, networked/IP-based media players등의 TV connected device에서 동작하는 드리머 서비스의 back-end system 개발. 
2) cloud 기반으로 전세계를 대상으로 서비스할 드리머 서버시스템의 지속적인 성능향상 작업

자격조건 Knowledge : .
 - Deep understanding of Java servlet/Jsp
 - Deep understanding of RDBMS.
 - Deep understanding of open standard based development

Skill : 
 -  Expert in OO design and implementation using Java
 -  Expert in java networking application development.
 -  Expert in enterprise application architecture.

업무내용 

- 서버 서비스 어플리케이션 개발팀원

- server-side application developer
- Cloud 기반 Server-side Java 어플리케이션 개발 
- 안정적이고 효율적으로 동작하는 서버 시스템 개발

주요 업무
1) Blu-ray, networked/IP-based media players등의 TV connected device에서 동작하는 드리머 서비스의 back-end system 개발. 
2) cloud 기반으로 전세계를 대상으로 서비스할 드리머 서버시스템의 지속적인 성능향상 작업

자격조건 Knowledge : .
 - Deep understanding of Java servlet/Jsp
 - Deep understanding of RDBMS.
 - Deep understanding of open standard based development

Skill : 
 -  Expert in OO design and implementation using Java
 -  Expert in java networking application development.
 -  Expert in enterprise application architecture.

Most of the time, client code cannot do anything about SQLExceptions. Do not hesitate to convert them into unchecked exceptions. Consider the following piece of code:

public void dataAccessCode()

{    

try{        ..some code that throws SQLException    }

catch(SQLException ex)

{        ex.printStacktrace();    }}

This catch block just suppresses the exception and does nothing. The justification is that there is nothing my client could do about an SQLException. How about dealing with it in the following manner?

public void dataAccessCode()

{    

try{        ..some code that throws SQLException    }

catch(SQLException ex){        

throw new RuntimeException(ex);    }}<--그젠가 상위클래스던,인터페이스던.. abstract으로 사용자가 재정의

해야할 Thread의 run() 같은 메서드에서 예외를 throw해야할 상황이 있을때 선생님께서 런타입으로 캐스팅

해서 넘기면 된다고 말씀하심.

This converts SQLException to RuntimeException. If SQLException occurs, the catch clause throws a newRuntimeException. The execution thread is suspended and the exception gets reported. However, I am not corrupting my business object layer with unnecessary exception handling, especially since it cannot do anything about an SQLException. If my catch needs the root exception cause, I can make use of thegetCause() method available in all exception classes as of JDK1.4.

If you are confident that the business layer can take some recovery action when SQLException occurs, you can convert it into a more meaningful checked exception. But I have found that just throwingRuntimeException suffices most of the time.

What is wrong with following code?

public class DuplicateUsernameException    extends Exception {}

It is not giving any useful information to the client code, other than an indicative exception name. Do not forget that Java Exception classes are like other classes, wherein you can add methods that you think the client code will invoke to get more information.

We could add useful methods to DuplicateUsernameException, such as:

public class DuplicateUsernameException    extends Exception  <-마찬가지로 배운것~(주문에 대한

재고수량 정보 리턴)

{    public DuplicateUsernameException         (String username){....} 

   public String requestedUsername(){...}    

public String[] availableNames(){...}}

The new version provides two useful methods: requestedUsername(), which returns the requested name, and availableNames(), which returns an array of available usernames similar to the one requested. The client could use these methods to inform that the requested username is not available and that other usernames are available. But if you are not going to add extra information, then just throw a standard exception:

throw new Exception("Username already taken");

Best Practices for Using Exceptions

The next set of best practices show how the client code should deal with an API that throws checked exceptions.

1. Always clean up after yourself <- 내가예전에 고민했던 결론 (자기의 업무 영역에 따른 책임분할)

If you are using resources like database connections or network connections, make sure you clean them up. If the API you are invoking uses only unchecked exceptions, you should still clean up resources after use, with try - finally blocks.

public void dataAccessCode(){

    Connection conn = null; 

   try{        conn = getConnection();    

    ..some code that throws SQLException    

}catch(SQLException ex)

{        ex.printStacktrace();    }

 finally{        DBUtil.closeConnection(conn);    }}

class DBUtil{    public static void closeConnection        

(Connection conn){        try{            conn.close();        } 

catch(SQLException ex){            

logger.error("Cannot close connection");          

  throw new RuntimeException(ex);        }   

 }}

DBUtil is a utility class that closes the Connection. The important point is the use of finally block, which executes whether or not an exception is caught. In this example, the finally closes the connection and throws a RuntimeException if there is problem with closing the connection.

2. Never use exceptions for flow control <- 내가 요 유혹에 빠지기도 했었음..

Generating stack traces is expensive and the value of a stack trace is in debugging. In a flow-control situation, the stack trace would be ignored, since the client just wants to know how to proceed.

In the code below, a custom exception, MaximumCountReachedException, is used to control the flow.

public void useExceptionsForFlowControl() 

{    

try {        while (true) 

{            increaseCount();        }   

 } catch (MaximumCountReachedException ex) 

{    }    //Continue execution

}

public void increaseCount()    throws MaximumCountReachedException 

{    if (count >= 5000)        throw new MaximumCountReachedException();

}

The useExceptionsForFlowControl() uses an infinite loop to increase the count until the exception is thrown. This not only makes the code difficult to read, but also makes it slower. Use exception handling only in exceptional situations.

3. Do not suppress or ignore exceptions <-몇일 전 까지 core api익셉션을 무조건 누르려고 했었음(현재는 발생

When a method from an API throws a checked exception, it is trying to tell you that you should take some counter action. If the checked exception does not make sense to you, do not hesitate to convert it into an unchecked exception and throw it again, but do not ignore it by catching it with {} and then continue as if nothing had happened.

4. Do not catch top-level exceptions <-- 노력해볼꼐요 -_-;  구현 과정중에 이것저것 신경쓸께 너무 많아져서

Unchecked exceptions inherit from the RuntimeException class, which in turn inherits from Exception. By catching the Exception class, you are also catching RuntimeException as in the following code:

try{..}catch(Exception ex){}

The code above ignores unchecked exceptions, as well.

5. Log exceptions just once

Logging the same exception stack trace more than once can confuse the programmer examining the stack trace about the original source of exception. So just log it once.