주의

아래에 쓴 것은 기본적으로 반모드이다.그러나 역모드에도 드문 상황에서 효과가 뛰어난 것이 섞여 있다.다음은 나도 거의 사용하지 않지만 그 상황에서 효과가 뛰어나다. 어떤 반도형에 대해 사육 방법을 설명한다.

갑작스럽지만 우선 예외에 대한 방침을 정했다

예외는 예외 상태에만 적용(Effective Java 프로젝트 39)

불필요한 느린 속도 검사 예외(동일 항목 41)

가급적 사용 기준 예외(동일 항목 42)

던진 모든 예외를 문서화

본래 나는 명작인 에펙티브 자바에 대들고 싶지 않았지만, 상술한 방침에 나도 전적으로 찬성한다.예외적으로 VM에서는 최적화 객체의 우선순위가 낮은 경우가 거의 없습니다.따라서 예외 처리를 최대한 하지 않기 위해 코드를 기술하면 성능이 높다.예외적으로 API 설계가 혼란스러워 API가 예외적으로 던지기보다는'사전'이 예외 상태인지 확인하는 수단을 마련하는 것이 사용자에게 코드의 유연성을 줄 수 있다.따라서 표준 예외를 우선적으로 사용하고 그 중에서 API 사용자가trycatch를 사용하도록 강제하는 검사 예외는 불필요하게 천천히 걷고 사용자가 사전에 알 수 있도록 한다.표준 예외는 한 단계 더 느리더라도 API 문서에서 발생할 수 있는 예외에 대해 자세히 설명해야 합니다.
그렇지만나는 가끔 이 최선의 실천을 일부러 헛디뎌서 코드를 만들 때가 있다고 솔직하게 말했다.아래의 코드를 쓴다는 것은 아니다.
Bad.java

    try {
        int i = 0;
        while (true) array[i++].doSomething();
    } catch (ArrayIndexOutOfBoundsException e) {}

이런 예는 통제 절차를 혼란스럽게 하는 뚜렷한 반모드이다.그러나 자바 이외에 특히 주목할 만한 특징은 한 번의 조작을 통해 심각한 방법 호출에서 회복할 수 있다는 것이다. 이것은 다른 방법에서는 실현할 수 없는 것이다.딱 C의 setjump longjump 같은 거야.(또는 역사의 순서는 당연히 상반된다) 이것이 어떻게 작용하는지, 예를 들어 몇 겹으로 겹치는 State 모델에서 가장 높은 State로 한 번에 바뀔 수 있다.나는 그가 무슨 말을 하고 있는지 모르겠기 때문에, 아래에서 구체적인 예를 들면서 상세하게 서술한다.

주식 시장의 주문이 일치하다.

당사는 금융시스템 SI를 운영하는 회사이기 때문에 주식시장의 매칭 엔진을 인코딩하는 경우도 있습니다.주식 거래를 하지 않은 독자를 위해 매매 주문서가 어떻게 일치하는지 간단히 설명하겠습니다.(아래 설명을 잘 모르면원작
우선 아침 조회 전부터 투자자들의 매매 주문서를 수집하기 시작한다.(8:00-9:00) 이를 책으로 적절하게 표시하고 9시가 되면'판 부치기'작업을 하여 거래를 성립시킨다.보드에서 보내온 곳은 조잡장이라고 불리는 상태가 됐고, 매매 성립 방법은 continuous auction이라고 불리는 방법으로 넘어갔다.시장에서는 기본적으로 매매가 연속적으로 진행되지만 매매 성립 가격이 큰 폭으로 변동이 많은 상황에서 매매 성립을 중지하는 것은 특별 시세(또는special quote)의 상태가 된다.특별한 징조 중 아까와 같은 조작으로 거래가 이루어지기를 기다리면서 일정 시간 간격으로 특별한 징조라는 특수한 가격을 표시하면서 행서의 업데이트를 진행한다.시장이 폐쇄될 시간이 되면 마지막으로 다시 한 번 판송하는 조작을 해서 매매가 성립되고 끝난다.
그림과 같다.

이를 실현하려면 상기 두 층이 겹치는 State 모드를 사용하는 것이 비교적 좋은지 이해할 수 있다.우리도 이렇게 이해하고 인코딩했다.그러나 나는 2층의 State 모드에서 실제 인코딩을 하는 과정에서 코드가 복잡해진다는 것을 알아차렸다.가장 큰 원인은 주문 매칭층에서 발생하는 각종 현상이 비교적 높은 시장 모델 자체의 변화를 초래했기 때문이다.따라서 우리는 아래 코드를 통해 낮은 State에서 예외를 던지면 비교적 높은 State 전환을 실현할 수 있다.
Sample.java

// このメソッドでまず最初に Event を受信、その後、MarketMode のインスタンス -> TradingMode のインスタンスと順に渡して行く
// ここで Event とは時間経過、もしくは売買注文が入ったことを示すオブジェクト
public void processEvent(Event event) {
        while (true) {
                try {
                        marketMode = marketMode.processEvent(event); // State パターン
                        return; // イベントを処理したら終了
                } catch (MarketModeChangedException e) {
                        marketMode = e.nextMarketMode;
                        // イベント処理中に市場モードが遷移してしまったのでreturn しない
                        // 同じイベントを再度、新しい市場モードで処理
                }
        }
}

private static class MarketModeChangedException extends Exception {
        // このアンチパターン内では例外のシングルトンを作っておくと良い(理由は後述)
        public static final MarketModeChangedException singleton = new MarketModeChangedException();

        public MarketMode nextMarketMode; // 次の市場モードを表現するオブジェクトをここに載せる
        // 詳細は省略
}

public static class MarketMode { // Stateパターンにより市場のモード(BeforeOpening Zaraba SpecialQuote Closing) を表現する
        public TradingMode tradingMode;
        public MarketMode processEvent(Event event) throws MarketModeChangedException {
                tradingMode = tradingMode.processEvent(event); // Stateパターン。ここでは下位のStateからの例外を意図的にスルー
        }
        // 詳細は省略
}

public static abstract class TradingMode { // Stateパターンにより注文取り扱いのモード (JustBooking Itayose ContinuousAuction SpecialQuoteAndBooking) を表現する
        public abstract TradingMode processEvent(Event event) throws MarketModeChangedException;
        // 詳細は省略
}

예를 들어 Market Mode: Zarab, Tradeing Mode:Continuus Auction 상태에서 Continuous Auction 내의 깊은 방법이 등급 내 가격 변동이 너무 크면 그 자리에서 M arket ModeChangException에 적합한 다음 상태(Market Mode:Special Quoite, Trading Mode:Special Qute And Booking)를 설정하여 던진다.처리되지 않은 이벤트는 다음(변환된) State에서 수신하여 계속 처리됩니다.

그다지 예외적이지 않은 예외를 사용하다

위에서 말한 바와 같이 나는 일부 설명을 끝냈고 때로는'예외가 아니다'를 사용할 만한 경우도 있었다.(잘 설명할 자신은 없지만...) 여기서 드디어 화제를 주제로 밀어붙일 수 있는'반모드적 사육법'.나는 이런 예외적인 용법을 사용하는 상황에서 기본적으로 처음에 말한 가장 좋은 실천과 상반되는 것이 비교적 좋다고 생각한다.
우선,'항목39: 예외는 예외 상태에서만 사용'은 본 반모드에서 원래 상반된 행위이다.또한, "항목 41: 검사 예외에 대해 불필요하게 천천히 걷기", "항목 42: 가능한 한 표준 예외를 사용하기"에 관해서는 반모드에서 비표준 검사 예외를 거꾸로 천천히 써야 한다.익숙하지 않은 비표준 예외가 무시되면 반모드 인코딩을 사용하는 특수 코드가 될 수 있기 때문이다.따라서 표기를 비검사 예외로 제거해서는 안 된다.또 표준예외를 사용하면 코드의 다른 부분에서 발생하는 표준예외와 섞이기 쉬워 절차를 바꾸려는 것인지 진짜 예외를 바꾸려는 것인지 판단하기 어려워 예상치 못한 오류를 만들기 쉽다.
마지막 항목인'항목 44: 모든 던지는 예외를 문서화한다'는 점에서 특별히 뒤집을 필요가 없다.물론 반모드로 인코딩된 것은 적당한 파일화가 필요하다.또한 이런 코드는 밀접하게 결합된 모듈 내 깊은 곳에 조용히 존재하는 것이 좋으며 API 등을 통해 천천히 걷는 것은 예외가 없는 디자인이 허용되지 않는다.
마지막으로 코드의 성능에 대해 설명을 했지만 노력만 하면 만족스러운 속도로 이동할 수 있는 경우가 많다.예선 제작 예외의 단식이다.예외적인 처리는 통상적으로 성능이 떨어지지만, 주로 창고 추적에 비용이 들기 때문이다.따라서 단식의 예외로 미리 만들어진 인코딩을 실행함으로써 성능 악화를 대부분 방지할 수 있다.
이상은'반모드적 사육 방법'에 관한 화제입니다.그러나 이런 조금 위험한 영역에서 자신을 보호하기 위해 진입하는 수법은 사회적으로 그렇게 정보로 널리 퍼지지 않는다.내가 알기로는 인코딩 안내서와 블로그에는 이런 수법에 대한 설명이 없다.그래서 이것은 단지'내 습관'의 사육 방법에 불과하다.이런 반모드를 사용할 때atyour own risk를 사용하세요. 더 좋은 다른 방법이나 반모드의 사육 방법이 있다면 알려주세요.