6.19.1 例外処理の概要 ¶

特定のエラーを捕まえる ¶

最もよくある例外処理のひとつは、組み込みあるいは ライブラリの手続きから発生した特定のエラーを捕捉するというものです。 guardマクロがこのような目的の場合に使えます。 コードは以下のような感じになるでしょう。

(guard (exc [(condition-has-type? exc <read-error>)
             (format #t "read error!")
             'read-error]
            [else 'other-error])
  (read-from-string "(abc"))

guard節の cadr 部は (variable clause …) という 形式です。この例では、変数は excで、2つの節があります。 それぞれの clause は cond と似た形式になります。

guard の cddr 部は本体で、式のリストです。この例では、式は (read-from-string "(abc") のひとつだけです。

guard はその本体部を実行するところから始めます。 read-from-string は構文エラーに出くわすと、<read-error>型の エラーを発生させます。guardフォームがこのエラーを捕捉し、 そのコンディションオブジェクトを変数excに束縛し、excの後の 節を、condと同じようにチェックします。この場合、投げられた コンディションは <read-error>なので、最初の節のテストを満し、 その節の残りの部分が実行されます。すなわち、"read error!" が 印字され、シンボル read-error が返ります。

他の言語を使い慣れていれば、同じパターンであることがわかると思います。 guard フォームの cddr 部は、C++やJavaの try 節、あるいは、 Common Lisp の handler-case の cadr 部に似ています。 また、guard フォームの cdadr 部は、catch 節あるいは、 handler-case の cddr 部に似ています。

テスト式においては、投げられたコンディションのタイプをチェックする のが普通です。condition-has-type? という関数が SRFI-35 で定義されていますが、これはちょっと冗長です。Gauche の コンディションクラスは述語のようにも使えるようになっており、上の 式は以下のように書くこともができます。

(guard (exc [(<read-error> exc)
             (format #t "read error!")
             'read-error]
            [else 'other-error])
  (read-from-string "(abc"))

注意事項: 一般的には、投げられたコンディションが特定の タイプであるかをチェックするのにis-a?は使えません。 コンディションが合成されたものである可能性があるからです。 合成されたコンディションについての 詳細は コンディション を参照してください。

もし、clause のどのテストも満されず、かつ else 節があたえられて いなければ、その例外は guard から「抜け」ます。すなわち、guard の外側のレベルあるいはトップレベルで処理されることになります。たとえば、 以下の guard フォームでは、<read-error> と <system-error> としか処理できず、もし、本体が他のタイプのコンディション を投げてきたら、その外側のレベルで処理しなければなりません。

(guard (exc [(<read-error> exc) (handle-read-error)]
            [(<system-error> exc) (handle-system-error)])
  body ...)

guardおよび他の低レベルの例外処理の構成についての詳細は 例外の処理 を参照してください。

自分のコードから例外を通知する ¶

例外を通知する一般的な方法は raise手続きを使うことです。

(raise condition)

conditionにはどんなオブジェクトでも渡すことができます。 それをどのように解釈するかはひとえに例外ハンドラにかかってます。 もし、コンディションとして整数があがってくるというのが判っていれば、 guard で以下のように捕捉することができます。

(guard (exc [(integer? exc) 'raised])
  (raise 3))

とはいうものの、<condition> あるいはそのサブクラスのインスタンスを 使うのが好ましいというのが通例です。condition マクロはコンディション オブジェクトを作成するのに使えます。以下の例は、いくつかのスロット値をもち それらを発生させるコンディションの作りかたを示したものです。

;; create and raise an error condition
(raise (condition
        (<error> (message "An error occurred."))))

;; create and raise a system error condition
(raise (condition
        (<system-error> (message "A system error occurred.")
                        (errno EINTR))))

condition マクロおよび、どのようなコンディションクラスが用意 されているかの詳細については コンディション を参照してください。

最も一般的なコンディションのタイプはエラーコンディションなので、 error および errorf という便利な手続きが 用意されています。これらはメッセージ付きのエラーコンディションを 生成し、それを発生させます。

;; `error' concatenates the arguments into a message.
(unless (integer? obj)
  (error "Integer expected, but got:" obj))

;; `errorf' uses format to create a message.
(unless (equal? x y)
  (errorf "~s and ~s don't match" x y))

いくつかの言語での例外を投げる機構、たとえば、 C++やJavaの throw はその継続を破棄します。これとは違い Schemeの raise はその呼び出し元へ戻ることができます。もし、 raise で元へもどらないで欲しいのなら、簡便な方法としては、 常にエラーコンディションの一つをわたるようにするというのがあります。 そうすると Gauche では raise は戻らないことを保証します。 raiseの詳細については、例外の通知を参照してください。

註: R7RSでは少し違ったセマンティクスを採用しています。 raiseは継続不可能な例外を投げるものとして(もし例外ハンドラから 制御が戻ってきたら、別のエラーを報告します)、 別に継続可能な例外を投げるraise-continuableという手続きを 設けました。R7RS環境にいるときは、本項のraiseではなく R7RS互換のraiseが見えるようになっています。

独自のコンディションを定義する ¶

独自のコンディションクラスを定義することが可能で、そうすることで、 アプリケーション固有の情報を例外が発生した点からハンドラへ渡すことが できます。

Gauche のフレームワーク(SRFI-35)に適合させるためには、新しく定義する コンディションクラスは組み込みの <condition> クラスあるいは その子孫を継承し、また、メタクラス <condition-meta> のインスタンスであることが望まれます。

可搬性を増すと同時に上の慣例を確実にするための方法のひとつは、 define-condition-typeマクロを使うことです。これは、 srfi.35で定義されています。

(define-condition-type <myapp-error> <error>
  myapp-error?
  (debug-info myapp-error-debug-info)
  (reason myapp-error-reason))

これは、(Gauche内のクラス)<myapp-err>を定義するもので、 このクラスにはmyapp-error?という述語とアクセサのあるスロット があります。こうすれば、以下のようなコードで新しいコンディション 型が使えます。

(guard (exc
         [(myapp-error? exc)
          (let ([debug-info (myapp-error-debug-info exc)]
                [reason (myapp-error-reason exc)])
            ... handle myapp-error ...)])
  ...
  ...
  (if (something-went-wrong)
    (raise (condition
             (<myapp-error> (debug-info "during processing xxx")
                            (reason "something went wrong")))))
  ...
  ...
  )

SRFIとの互換性が重要でないなら、Gaucheの拡張されたerror手続きを 使うと<error>のサブタイプであるコンディションを投げるコードを より簡潔に書くことができます。

  (if (something-went-wrong)
    (error <myapp-error>
           :debug-info "during processing xxx"
           :reason "something went wrong"))

Gauche のオブジェクトシステムでコンディション型がどのように実装されているかは define-condition-typeマクロの解説を参照してください。

6.19.2 例外の通知 ¶

エラーの通知 ¶

最も良くある例外ケースはエラーです。単純なエラーを通知するために、 ふたつの簡単な関数が用意されています。 複合コンディションを通知する必要がある場合は 下で説明するraise手続きを使って下さい。

Function: error string arg … ¶

Function: error condition-type keyword-arg … string arg … ¶

[R7RS+ base][SRFI-23+] エラーを通知します。最初の形式は、 stringとarg …からなるメッセージを持つ <error>コンディションを作成それをraiseします。 この形式はR7RS及びSRFI-23のerrorと互換です。

gosh> (define (check-integer x)
        (unless (integer? x)
           (error "Integer required, but got:" x)))
check-integer
gosh> (check-integer "a")
*** ERROR: Integer required, but got: "a"
Stack Trace:
_______________________________________

2番目の形式は<error>以外のエラーコンディションを通知したいときに 使います。condition-typeはコンディションタイプ でなければなりません (コンディションタイプについてはコンディションを 参照して下さい)。その後に、キーワードと値のリストを与えることで コンディションのスロットを初期化することができます。また、その後に メッセージを構成する文字列と他のオブジェクトのリストを与えることができます。

(define-condition-type <my-error> <error> #f
  (reason)
  (priority))

...
  (unless (memq operation *supported-operations*)
    (error <my-error>
           :reason 'not-supported :priority 'urgent
           "Operation not supported:" operation))
...

Function: errorf fmt-string arg … ¶

Function: errorf condition-type keyword-arg … fmt-string arg … ¶

errorに似ていますが、エラーメッセージはformatによりフォーマット されます。すなわち、最初のフォームは以下と等価です。

(define (errorf fmt . args)
  (error (apply format #f fmt args)))

2番目の形式は<error>以外のエラーコンディションを通知するのに 使えます。condition-type, keyword-argの意味については errorと同じです。

一般的な条件の通知 ¶

Function: raise condition ¶

[SRFI-18][R7RS base] これは、例外事態を通知する基本となるメカニズムです。

この手続きは現在の例外ハンドラを呼び出します。引数conditionは 例外の性質を表現するのに使われ、例外ハンドラに渡されます。 Gaucheの組み込み手続きやライブラリ手続きは常に、<condition>クラス もしくはそのサブクラスのインスタンスをconditionとして用いますが、 ユーザは任意のオブジェクトをraiseに渡すこともできます。 渡されたconditionの解釈は例外ハンドラに任されます。

注意事項: いくつかの主流の言語では、例外を「投げる」と制御はそこに 戻りません。Gaucheではraiseから戻って来れるように セットアップすることが可能です。詳細は例外の処理を 参照してください。

raiseから戻って来ることが無いようにしたい場合は、 <serious-condition>やそのサブクラスのインスタンスをcondition としてraiseに渡すのが確実です。 組み込みコンディションのクラス階層についてはコンディションを参照して下さい。

R7RSではやや異なるセマンティクスを採用しています。R7RSのraiseは 決して戻りません—もしハンドラが戻ってきた場合は、別の例外が投げられます。 R7RSはraise-continuableという別の手続きで、ハンドラから 戻っても良いことを明示します。ポータブルなプログラムでは、 raiseには常に<serious-condition>かそのサブクラスを 渡すようにするのが良いでしょう。

6.19.3 例外の処理 ¶

;; 低レベルな例外メカニズムの概念的な実装
;; %xhは例外ハンドラのリスト

(define (current-exception-handler) (car %xh))

(define (raise exn)
  (let ((prev %xh))
    (dynamic-wind
      (lambda () (set! %xh (cdr %xh)))
      (lambda ()
        (receive r ((current-exception-handler) exn)
          (if (uncontinuable-exception? exn)
            (raise (make-error "returned from uncontinuable exception"))
            (apply values r))))
      (lambda () (set! %xh prev)))))

(define (with-exception-handler handler thunk)
  (let ((prev %xh))
    (dynamic-wind
      (lambda () (set! %xh (cons handler %xh)))
      thunk
      (lambda () (set! %xh prev)))))

6.19.4 コンディション ¶

組み込みコンディションクラス ¶

現在のところGaucheには以下の組み込みコンディションクラスの階層があります。 これは、おおよそのところ SRFI-35 および SRFI-36 のコンディションの階層を 反映したものですが、Gauche風のクラス名になっています。対応する SRFI の コンディションタイプがあるものについては、SRFI でのクラス名も使えます。

  <condition>
    +- <compound-condition>
    +- <serious-condition>
    |    +- <serious-compound-condition> ; also inherits <compound-condition>
    +- <message-condition>
         +- <error>                      ; also inherits <serious-condition>
              +- <system-error>
              +- <unhandled-signal-error>
              +- <continuation-violation>
              +- <read-error>
              +- <io-error>
                   +- <port-error>
                        +- <io-read-error>
                        |    +- <io-decoding-error>
                        +- <io-write-error>
                        |    +- <io-encoding-error>
                        +- <io-closed-error>
                        +- <io-unit-error>
                        +- <io-invalid-position-error>

いくつかのコンディションが同時に発生することがあることに注意してください。 たとえば、ファイルの読み込がデバイスの欠陥により失敗した場合は、 <system-error> および <io-read-error> の両方からなる エラーとなるでしょう。 このような場合、合成したコンディション (compound condition) が発生します。 したがって、たとえば、<io-read-error> が投げられたかどうかをチェック するのに、単に (is-a? obj <io-read-error>) を使えばよいというわけ にはいきません。 後述の「コンディション API」の節を参照してください。

Metaclass: <condition-meta> ¶

すべてのコンディションクラスはこのクラスのインスタンスです。 このクラスは object-apply を定義していますので、 コンディションクラスは述語として使うことができます。たとえば、

(<error> obj) ≡ (condition-has-type? obj <error>)

Class: <condition> ¶

Condition Type: &condition ¶

[SRFI-35] コンディションの階層のルートクラスです。

Class: <compound-condition> ¶

合成コンディションを表現します。合成コンディションは make-compound-condition を用いて1つ以上のコンディションから 生成することができます。このクラスを直接使ってはいけません。

合成コンディションはcondition-has-type? に対して、 元のコンディションのどれかが、与えられたタイプなら、#t を返します。

Class: <serious-condition> ¶

Condition Type: &serious ¶

[SRFI-35] このクラスのコンディションは無視して先を続けることはできない深刻な 状況のためにあります。特に、このタイプのコンディションを raise したら、それは元には絶対に戻らないと考えて問題ありません。

Class: <serious-compound-condition> ¶

深刻なコンディションを含む合成コンディションを表現するための 内部クラスです。<compound-condition> および <serious-condition> の両方を継承しています。 make-compound-condition は深刻なコンディションを含む複数の コンディションを渡されると、このクラスを使います。このクラスを 直接使ってはいけません。

Class: <message-condition> ¶

Condition Type: &message ¶

[SRFI-35] このクラスはメッセージ付のコンディションを表現し、スロットを一つ もっています。

Instance Variable of <message-condition>: message ¶

メッセージ

Class: <error> ¶

Condition Type: &error ¶

[SRFI-35] エラーを表します。<serious-condition> および <message-condition> を継承しています。したがって、 message スロットを持っています。

注意事項: SRFI-35 の&errorコンディションは &serious のみを継承し、&message は継承していません。したがって、 このエラーコンディションにメッセージを付与するためには、 合成コンディションを使わなければなりません。Gauche は 主として過去のバージョンとの互換性を確保するために、 ここで多重継承を用いています。 可搬性のあるコードを書くには、以下のようにメッセージコンディション 付きのエラーコンディションを使うべきです。

(condition
  (&message (message "Error message"))
  (&error))

Function: message-condition? obj ¶

Function: serious-condition? obj ¶

Function: error? obj ¶

[SRFI-35] これらはSRFI-35互換の述語で、それぞれobjが &message、&serious、あるいは&error型のコンディションであるか どうかを検査します。

Class: <system-error> ¶

<error> のサブクラス。 システムコールがエラーを返したとき、この型の例外が投げられます。 message スロットには通常エラーの(strerror(3)のような)説明が 含まれています。それ以外に、このクラスにはもうひとつ次のような インスタンススロットがあります。

Instance Variable of <system-error>: errno ¶

システムのエラー番号の整数値を持ちます。

エラー番号はシステムによって異なる可能性があります。Gaucheは典型的な Unixのエラー番号に対して定数を定義している(例: EACCES, EBADF)ので、 それを使うと良いでしょう。定義されている定数に関しては システムへの問い合わせのsys-strerrorの説明を参照してください。

このクラスには対応する SRFI のコンディションタイプがありませんが、 OSの生のエラーコードを取得するのに重要です。いくつかのケースで このタイプのコンディションは他の、たとえば <io-read-error> のようなコンディションと合成されます。

Class: <unhandled-signal-error> ¶

<error>のサブクラス。多くのシグナルのデフォルトハンドラは このコンディションを投げます。詳しくはシグナルの処理を 参照してください。

Instance Variable of <unhandled-signal-error>: signal ¶

受け取ったシグナル番号を示す整数値。典型的なシグナル番号については 定数が定義されています。シグナルとシグナルセットを参照のこと。

Class: <read-error> ¶

Condition Type: &read-error ¶

[SRFI-36] <error> のサブクラス。リーダがS式を読み込み中に、字句エラー または構文エラーを検出したとき、この型のコンディションが投げられます。

Instance Variable of <read-error>: port ¶

リーダがS式を読みこんでいたポート。 (註: SRFI-36 の &read-error はこのスロットを定義していません。 ポータブルなプログラムを書く場合はこのスロットを使わないで下さい)。

Instance Variable of <read-error>: line ¶

リーダがこのエラーを発生させたときの入力行カウント(1がベース)。 リーダが行カウントを保持しないポートから読み込むときには、-1 となる。

Instance Variable of <read-error>: column ¶

Instance Variable of <read-error>: position ¶

Instance Variable of <read-error>: span ¶

これらのスロットは、SRFI-36 の &read-error で定義されています。 今のところ、これらのスロットは常に #f を保持するようになっています。

Class: <io-error> ¶

Condition Type: &io-error ¶

[SRFI-36] I/O エラーのベースとなるクラス。<error> を継承しています。

Class: <port-error> ¶

Condition Type: &io-port-error ¶

[SRFI-36] ポート関連の I/O エラー。<io-error> を継承しています。

Instance Variable of <port-error>: port ¶

エラーを起したポートを保持。

Class: <io-read-error> ¶

Condition Type: &io-read-error ¶

[SRFI-36] ポートから読み込み中の I/O エラー。<port-error> を継承しています。

Class: <io-write-error> ¶

Condition Type: &io-write-error ¶

[SRFI-36] ポートへの書き出し中の I/O エラー。<port-error> を継承しています。

Class: <io-closed-error> ¶

Condition Type: &io-closed-error ¶

[SRFI-36] クローズされたポートで読み込み/書き出しをしようしたときの I/O エラー。 <port-error> を継承しています。

Class: <io-unit-error> ¶

対象となるポートでサポートされていない単位での読み/書き要求 (たとえば、キャラクタ専用ポートでのバイナリ I/O 要求)の際の I/O エラー。 <port-error> を継承しています。

Class: <continuation-violation> ¶

Condition Type: &continuation ¶

[SRFI-226] 継続に関する制約が破られた場合に投げられるエラーです。 典型的なのは、指定された継続プロンプトタグがコンテクスト中に見つからない場合です。 詳しくは継続プロンプトを参照してください。

Function: make-continuation-violation prompt-tag ¶

[SRFI-226] <continuation-violation>コンディションを作ります。 prompt-tagは原因となった継続プロンプトタグです。

Function: continuation-violation? obj ¶

[SRFI-226] objが<continuation-violation>コンディションなら #tを、そうでなければ#fを返します。

Function: continuation-violation-prompt-tag condition ¶

[SRFI-226] <continuation-violation>コンディションであるconditionの、 prompt-tagスロットの値を取り出します。

コンディションAPI ¶

Macro: define-condition-type name supertype predicate field-spec … ¶

[SRFI-35+] 新しいコンディションタイプを定義します。Gaucheでは、コンディションタイプは クラスであり、そのメタクラスは <condition-meta> です。

name が新しいタイプの名前になり、この名前の変数が作成された コンディションタイプに束縛されます。supertype はこのコンディション タイプのスーパータイプ(直接のスーパークラス)の名前です。コンディション タイプは <condition> を継承するか、その子孫を継承しなければ なりません。(この形式では、多重継承を指定することはできません。 一般的にいって、コンディションタイプの階層の中では多重継承は避ける べきです。そのかわりに、合成コンディションを使えます。合成コンディションは 多重継承を使いません。)

変数 predicate はこのコンディションタイプ用の述語手続きに 束縛されます。

各 field-spec は (field-name accessor-name) の形式で このコンディションは、フィールド名は field-name で決まります。 変数 accessor-name はそのフィールドにアクセスする手続きに 束縛されます。Gauche では、それぞれのフィールドは生成された クラスのスロットとなります。

GaucheはSRFI-35を拡張して、predicateやaccessor-nameを 定義する必要が無い場合はその位置に#fを指定できるようにしています。 accessor-nameが必要無い場合はそれを省略することもできます。

define-condition-typeがクラス定義に展開される際に、 各スロットは:init-keywordスロットオプションにスロット名と 同名のキーワードを取るように定義されます。

Function: condition-type? obj ¶

[SRFI-35] objがコンディションタイプである場合で、その場合にかぎり、 #t を返します。Gauche では (is-a? obj <condition-meta>) と同じです。

Function: make-condition-type name parent field-names ¶

[SRFI-35] 新しいコンディションタイプを生成する手続き版です。

Function: make-condition type field-name value … ¶

[SRFI-35] コンディションタイプ type のコンディションを生成し、 field-name および value のペアで指定されたように フィールドを初期化します。

Function: condition? obj ¶

[SRFI-35] obj がコンディションである場合で、その場合にかぎり、 #t を返します。Gauche では (is-a? obj <condition>) と 同じです。

Function: condition-has-type? obj type ¶

[SRFI-35] obj がコンディションタイプ type に属している場合で、その 場合にかぎり、#t を返します。合成コンディションがあるので、 これは、is-a? と同じではありません

Function: condition-ref condition field-name ¶

[SRFI-35] condition のフィールド field-name の値を検索します。 condition が合成コンディションであれば、元のコンディションの フィールドにアクセスできます。もし、複数の元のコンディションが、 field-name を持つ場合には、最初に make-compound-condition に渡されたものが優先されます。

コンディションのフィールドにアクセスするには、slot-ref および ref の両方あるいはどちらかを使えます。合成コンディションでは、 slot-missing メソッドが定義されますので、slot-ref は あたかも、合成コンディションが元になったコンディションの全てのスロットを もつかのように振舞います。しかしながら、condition-ref を 使う方が可搬性が増します。

Function: condition-message condition :optional fallback ¶

[SRFI-35+] conditionが<message-condition>を持っていれば そのmessageスロットを、そうでなければfallbackを返す手続きです。 fallbackが省略された場合は#fが指定されたとみなします。

投げられたコンディションを一度捕まえてメッセージを記録したりユーザに見せたりする 一般的なコードはよくあります。Schemeでは任意のオブジェクトをraiseできるため、 捕まえたコンディションがメッセージスロットを持っているとは限りません。 従ってそういったコードはいちいちコンディションの型を検査して分岐することになります。 そのパターンは充分によくあるので、この手続きが追加されました。

Function: make-compound-condition condition0 condition1 … ¶

[SRFI-35] condition0 condition1 … のすべてを持つ合成コンディション を返します。返されたコンディションのフィールドは、与えられたコンディション のすべてのフィールドの和集合になります。同じ名前のフィールドを持つ コンディションがある場合には最初に与えられものが優先されます。 返されたコンディションは元になったコンディションのすべてのタイプの コンディションタイプをもつことになります。 (これは多重継承ではありません。上の <compound-condition> を参照)

Function: extract-condition condition condition-type ¶

[SRFI-35] condition はコンディションで、condition-typeタイプで なければなりません。この手続きは condition-type のコンディション を返し、condition からとりだされた値のフィールドを持ちます。

Macro: condition type-field-binding … ¶

[SRFI-35] コンディションを生成するのに便利なマクロ。 合成されたコンディションも生成できます。 Type-field-binding は、 (condition-type (field-name value-expr) …) という形式になります。

(condition
  (type0 (field00 value00) ...)
  (type1 (field10 value10) ...)
  ...)
 ≡
(make-compound-condition
  (make-condition type0 'field00 value00 ...)
  (make-condition type1 'field10 value10 ...)
  ...)