【PowerShell】`throw` によるエラー発生・例外処理の徹底解説

はじめに

PowerShellは、システム管理や自動化において非常に強力なツールです。しかし、スクリプトが常に予期した通りに動作するとは限りません。ファイルが見つからない、ネットワーク接続に失敗する、必要な権限がないなど、さまざまな理由でエラーが発生する可能性があります。

信頼性の高いスクリプトを作成するためには、これらのエラーを適切に検出し、処理することが不可欠です。エラーを無視したり、単にスクリプトが途中で停止したりするだけでは、問題の特定や解決が困難になり、自動化のメリットが失われてしまいます。

PowerShellには、エラーを扱うためのいくつかのメカニズムがあります。その中でも、意図的に「終了するエラー（Terminating Error）」を発生させるための主要なキーワードが throw です。そして、発生したエラーを捕捉し、スクリプトの実行を継続させたり、代替処理を行ったり、適切な終了処理を行ったりするための構文が try...catch...finally ブロックです。

この記事では、PowerShellのエラーの基本的な概念から始まり、throw キーワードの機能と使い方、そして throw と組み合わせて使う try...catch...finally による例外処理の仕組みについて、詳細かつ網羅的に解説します。約5000語をかけて、これらのトピックを深く掘り下げ、堅牢なPowerShellスクリプトを作成するための知識を徹底的に習得することを目指します。

PowerShellのエラーの基本

throw と try...catch...finally を理解する前に、PowerShellがどのようにエラーを扱っているかの基本的な概念を把握しておく必要があります。PowerShellには、主に2種類のエラーが存在します。

終了しないエラー (Non-terminating Error)
- これは、コマンドレットやスクリプトが報告するエラーのうち、スクリプトの実行を中断しないエラーです。
- 例えば、Get-ChildItem コマンドで存在しないパスを指定した場合、エラーメッセージは表示されますが、スクリプト自体は次の行に進みます。
- これらのエラーは、ErrorRecord オブジェクトとして $Error 自動変数に格納されます。
- Write-Error コマンドレットを使って発生させることができます。
終了するエラー (Terminating Error)
- これは、エラーが発生した時点でスクリプトの実行が中断されるエラーです。
- 例えば、存在しないコマンドレットを実行しようとしたり、致命的な実行時エラーが発生したりした場合などがこれに該当します。
- throw キーワードは、この「終了するエラー」を意図的に発生させるために使用されます。
- これらのエラーも ErrorRecord オブジェクトに関連付けられますが、通常は捕捉されない限りスクリプトの実行を停止させます。

どちらのタイプのエラーも、内部的には System.Management.Automation.ErrorRecord オブジェクトとして表現されます。このオブジェクトには、エラーメッセージ、エラーの発生元、スタックトレースなど、エラーに関する詳細な情報が含まれています。

エラーの処理方法は、ErrorAction Preference 変数 ($ErrorActionPreference) および共通パラメーター -ErrorAction によって制御されます。

$ErrorActionPreference: PowerShellセッション全体、またはスクリプトのデフォルトのエラー処理方法を決定します。以下の値があります。
- Continue (デフォルト): エラーメッセージを表示し、実行を継続します（終了しないエラーのデフォルト）。
- SilentlyContinue: エラーメッセージを表示せず、実行を継続します。
- Stop: エラーが発生した場合、その時点で実行を中断し、終了するエラーとして扱います。throw と似た効果ですが、これは主にコマンドレットが発生させる終了しないエラーに対して強制的に実行中断させるために使います。
- Inquire: エラー発生時にユーザーに続行するかどうかを問い合わせます。
- Suspend: ワークフローでのみ有効です。
- Break: デバッガーを呼び出します。
-ErrorAction: ほとんどのコマンドレットで利用可能な共通パラメーターで、その特定のコマンドレットのエラー処理方法を一時的に変更します。値は $ErrorActionPreference と同じです。これにより、グローバルな設定を上書きできます。

例：
“`powershell

存在しないファイルに対する Get-Content (通常は終了しないエラー)

デフォルト ($ErrorActionPreference = ‘Continue’) の挙動

Get-Content C:\NonExistentFile.txt
Write-Host “この行は実行されます” # エラー後も実行は続く

Write-Host “—“

-ErrorAction Stop を使用して強制的に終了するエラーにする

try {
Get-Content C:\NonExistentFile.txt -ErrorAction Stop
Write-Host “この行は実行されません” # Stop が発生したので実行されない
}
catch {
Write-Host “エラーを捕捉しました: $($_.Exception.Message)”
}
Write-Host “try…catch ブロックの外に出ました”
“`

この例からわかるように、-ErrorAction Stop は、本来終了しないエラーとして設計されているコマンドレットのエラーを、終了するエラーに昇格させるために使用できます。そして、終了するエラーは try...catch ブロックで捕捉できます。

throw キーワードは、最初から「終了するエラー」を発生させることを目的としています。これにより、スクリプト内で特定の条件が満たされた場合に、実行を意図的に中断し、そのエラーを try...catch ブロックで処理できるようにします。

`throw` キーワードとは

throw キーワードは、PowerShellスクリプトや関数の中で、意図的に終了するエラー（Terminating Error）を発生させるために使用されます。これは、プログラミング言語における「例外をスローする」操作に相当します。

基本的な構文は非常にシンプルです。

powershell throw [オブジェクト]

[オブジェクト] の部分には、エラーとして関連付けたい情報を指定します。最も一般的には、エラーメッセージを含む文字列や、エラーの詳細を保持するオブジェクトを指定します。

`throw` の基本的な使い方

1. 文字列を `throw` する

最も簡単な使い方は、エラーメッセージを含む文字列を指定することです。

“`powershell

例1: シンプルな文字列を throw

function Check-Value {
param([int]$Value)

if ($Value -lt 0) {
    throw "値が負数です: $Value"
}
Write-Host "値はOKです: $Value"

}

Write-Host “正の値の場合:”
Check-Value -Value 10

Write-Host “`n負の値の場合 (try…catch なし):”

try…catch で捕捉しない場合、ここでスクリプトが停止する

Check-Value -Value -5

Write-Host “`n負の値の場合 (try…catch あり):”
try {
Check-Value -Value -5
}
catch {
Write-Host “エラーを捕捉しました!”
Write-Host “エラーメッセージ: $($.Exception.Message)”
Write-Host “エラータイプ: $($.Exception.GetType().FullName)”
}

Write-Host “`nスクリプトは続行されています。”
“`

この例では、Check-Value 関数内で $Value が負数だった場合に、throw “値が負数です: $Value” を実行しています。

try...catch ブロックの外で Check-Value -Value -5 を実行すると、throw が評価された時点でスクリプトは停止します。エラーメッセージが表示され、それ以降のコードは実行されません。
try...catch ブロックの中で Check-Value -Value -5 を実行すると、throw が発生させた終了するエラーは catch ブロックによって捕捉されます。そして catch ブロック内のコードが実行され、その後 try...catch ブロックに続くコードの実行が継続されます。

文字列を throw した場合、PowerShellは内部的にその文字列を含む System.Management.Automation.RuntimeException という標準的な例外オブジェクトを作成し、それをスローします。catch ブロックの $_ 変数（直前に発生したエラーレコード）を見ると、その Exception プロパティが RuntimeException であることが確認できます。

2. オブジェクトを `throw` する

throw は文字列だけでなく、任意のオブジェクトを受け取ることができます。最も一般的なのは、System.Exception またはその派生クラスのオブジェクトを throw することです。これにより、エラーに関するより構造化された、詳細な情報を提供できます。

“`powershell

例2: System.Exception オブジェクトを throw

function Process-File {
param([string]$Path)

if (-not (Test-Path -Path $Path -PathType Leaf)) {
    $errorMessage = "指定されたファイルが見つかりません: $Path"
    # System.IO.FileNotFoundException はファイル操作エラーでよく使われる標準例外
    $exception = New-Object System.IO.FileNotFoundException $errorMessage, $Path
    throw $exception
}

# ファイル処理のロジック (ここでは省略)
Write-Host "ファイルを処理しました: $Path"

}

Write-Host “存在するファイルの場合:”

一時ファイルを作成してテスト

$tempFile = [System.IO.Path]::GetTempFileName()
Process-File -Path $tempFile
Remove-Item -Path $tempFile # テスト後削除

Write-Host “`n存在しないファイルの場合:”
try {
Process-File -Path “C:\NonExistent\File.txt”
}
catch {
Write-Host “エラーを捕捉しました!”
Write-Host “エラーメッセージ: $($.Exception.Message)”
Write-Host “エラータイプ: $($.Exception.GetType().FullName)”
Write-Host “追加情報 (もしあれば): $($_.Exception.FileName)” # FileNotFoundException のプロパティ
}

Write-Host “`nスクリプトは続行されています。”
“`

この例では、System.IO.FileNotFoundException オブジェクトを作成して throw しています。catch ブロックでは、捕捉したエラーの Exception プロパティから、例外のタイプ（System.IO.FileNotFoundException）や、ファイル名などの特定のプロパティ（この場合は FileName）にアクセスできます。標準の例外クラスを利用することで、エラーの種類を明確に区別し、catch ブロックで特定のタイプのエラーだけを捕捉する、といった高度なエラー処理が可能になります。

throw は、PowerShellスクリプトの実行フローを制御するための強力なメカニズムです。「この条件が満たされたら、それ以上処理を続行せず、このエラーが発生したことを周囲に伝えたい」という場合に最適です。この「周囲に伝える」というのが、try...catch...finally ブロックへの連携を意味します。

なぜ `throw` を使うのか

意図的なエラー発生: 特定のビジネスロジック違反（例: 必須パラメーターの欠如、不正な値、前提条件の不成立など）が発生した場合に、それをエラーとして明示的に報告したい。
スクリプトの停止: 致命的な問題が発生し、それ以上スクリプトを実行しても意味がない、または危険な場合に、安全に実行を中断したい。
例外処理への連携: try...catch ブロックと連携して、エラー発生時の代替処理、ログ記録、リソースのクリーンアップなどを実行したい。throw されたエラーだけが try...catch の catch ブロックで捕捉されます。Write-Error で発生させた終了しないエラーは、デフォルトでは catch されません（-ErrorAction Stop を使わない限り）。

`try...catch...finally` ブロックによる例外処理

throw によって発生した終了するエラーは、適切に処理されないとスクリプトの実行を中断させてしまいます。これを回避し、エラー発生時にも回復やクリーンアップの処理を実行できるようにするのが try...catch...finally ブロックです。これは多くのプログラミング言語にある例外処理のメカニズムと同様です。

構文は以下のようになります。

powershell try { # エラーが発生する可能性のあるコード # 例: throw キーワードの使用、-ErrorAction Stop を指定したコマンドレット呼び出し # 存在しないコマンドレットの実行など } catch [型指定された例外] { # [型指定された例外] が発生した場合に実行されるコード # $_ 変数にエラー情報が格納される } catch { # 上記のどの catch ブロックにも一致しない、あらゆる種類の終了するエラーが発生した場合に実行されるコード # これは「ジェネリックな catch」と呼ばれる } finally { # try ブロックのコードが正常に完了したか、 # あるいは catch ブロックが実行されたかに関わらず、 # 必ず実行されるコード (リソースのクリーンアップなど) }

各ブロックの役割を詳しく見ていきましょう。

`try` ブロック

try ブロックには、エラーが発生する可能性があるコードを配置します。ここで発生した「終了するエラー」が、後続の catch ブロックによって捕捉される対象となります。

終了しないエラーが try ブロック内で発生した場合、それは catch ブロックでは捕捉されません（ただし、前述の -ErrorAction Stop を使って終了するエラーに昇格させた場合は別です）。終了しないエラーは $Error 変数に記録され、スクリプトの実行は継続されます（$ErrorActionPreference の設定に従って）。

したがって、try ブロックは主に throw や -ErrorAction Stop、あるいは予期せぬランタイムエラー（ゼロ除算など）が発生する可能性のある処理を囲むために使用します。

`catch` ブロック

catch ブロックは、try ブロック内で発生した「終了するエラー」を捕捉し、そのエラーに対する処理を行うためのブロックです。エラーがtryブロックで発生した場合、PowerShellはエラーのタイプやその他の情報に基づいて、一致するcatchブロックを探します。

`catch` の種類

型指定された catch: 特定の種類の例外（エラー）だけを捕捉したい場合に、catch キーワードの直後に例外の .NET 型名を角かっこ [] で囲んで指定します。例えば、catch [System.IO.FileNotFoundException] や catch [System.Net.WebException] のように指定します。複数の型指定された catch ブロックを記述することも可能です。その場合、PowerShellは上から順に例外の型を比較し、最初に一致した catch ブロックを実行します。より具体的な例外型を先に書くのが一般的です。
ジェネリックな catch: 型指定を省略した catch ブロックは、その前に記述されたどの型指定された catch ブロックにも一致しなかった、あらゆる種類の終了するエラーを捕捉します。これは通常、最も広い範囲のエラーを捕捉するための最後の catch ブロックとして使用します。

エラーが捕捉されると、そのエラーに関する詳細な情報が自動変数 $_ に格納されます。$_ は System.Management.Automation.ErrorRecord オブジェクトであり、以下の重要なプロパティを持っています。

$_ .Exception: 発生した元の例外オブジェクトです。このオブジェクトの型やプロパティを調べることで、エラーの詳細を把握できます。例えば、$_.Exception.Message はエラーメッセージ文字列、$_.Exception.GetType().FullName は例外の完全な型名を示します。
$_ .InvocationInfo: エラーが発生したスクリプト内の場所（ファイル名、行番号、列番号）や、呼び出されたコマンドレット/関数などの情報が含まれます。$_.InvocationInfo.ScriptStackTrace はスタックトレースを提供します。
$_ .CategoryInfo: エラーのカテゴリ情報（アクティビティ、理由、ターゲットなど）が含まれます。

捕捉したエラーの処理

catch ブロック内では、捕捉したエラー情報（主に $_ を通じてアクセス）を利用して、さまざまな処理を実行できます。

エラー情報の表示/ログ記録: $_.Exception.Message や $_.InvocationInfo.ScriptStackTrace などの情報をコンソールに表示したり、ログファイルに書き込んだりします。
代替処理の実行: エラーが発生しても続行可能な場合、問題のある処理をスキップしたり、別の方法で同じタスクを実行したりします。
エラーの再スロー (throw): 捕捉したエラーを完全に処理できない場合や、呼び出し元にエラーを再度報告する必要がある場合、catch ブロック内で再び throw キーワードを使用します。単に throw とだけ記述すると、捕捉したときと同じエラーオブジェクトが再スローされます。これにより、エラー処理の責任を呼び出し元に移譲できます。
ユーザーへのフィードバック: エラーが発生したことをユーザーに分かりやすく伝えるメッセージを表示します。

例：
powershell try { # ファイル操作でエラーが発生する可能性のあるコード Get-Content -Path "NonExistentFile.txt" -ErrorAction Stop # または throw "ファイル操作エラー" } catch [System.IO.FileNotFoundException] { Write-Warning "警告: 指定されたファイルが見つかりませんでした。処理をスキップします。" Write-Verbose "エラー詳細: $($_.Exception.Message)" -Verbose:$true # 代替処理やログ記録など } catch [System.IO.IOException] { Write-Error "エラー: ファイル操作中にIOエラーが発生しました。" Write-Error "詳細: $($_.Exception.Message)" Write-Error "スタックトレース: $($_.InvocationInfo.ScriptStackTrace)" # 処理を停止するか、再試行するかなどの判断 # throw # 呼び出し元にエラーを伝えるため、再スローする場合 } catch { # ジェネリックな catch Write-Error "予期しないエラーが発生しました！" Write-Error "エラータイプ: $($_.Exception.GetType().FullName)" Write-Error "メッセージ: $($_.Exception.Message)" # ログ記録や管理者に通知など }

`finally` ブロック

finally ブロックはオプションですが、try ブロックのコードが正常に完了したか、または catch ブロックが実行されたかに関わらず、必ず実行されるコードを記述します。これは主に、リソースのクリーンアップ（開いたファイルのハンドルを閉じる、ネットワーク接続を切断する、一時ファイルを削除するなど）に使用されます。

finally ブロックは、try ブロック内でエラーが発生せず正常終了した場合でも、catch ブロックでエラーが捕捉された場合でも、あるいはtryブロック内で捕捉されない終了するエラーが発生してスクリプトが中断される直前でも、可能な限り実行されます。

例：
“`powershell

例3: finally ブロックによるクリーンアップ

function Process-Resource {
param([string]$ResourceIdentifier)

$resource = $null
try {
    Write-Host "リソース '$ResourceIdentifier' を開いています..."
    # リソースを開く処理 (失敗する可能性あり)
    # 例として、ここでは特定の識別子の場合は失敗させる
    if ($ResourceIdentifier -eq "BadResource") {
        throw "リソース '$ResourceIdentifier' を開けませんでした"
    }
    $resource = "Opened:$ResourceIdentifier" # リソースが開けた状態を模倣
    Write-Host "リソース '$ResourceIdentifier' を処理しています..."

    # リソースを使った処理 (エラー発生の可能性あり)
    # 例として、ここでも特定の条件で失敗させる
    # throw "リソース処理中のエラー"

    Write-Host "リソース '$ResourceIdentifier' の処理が完了しました。"

}
catch {
    Write-Host "エラーが発生しました: $($_.Exception.Message)"
    # エラーからの回復処理など
}
finally {
    # リソースが開かれている場合は必ず閉じる
    if ($resource -ne $null) {
        Write-Host "リソース '$ResourceIdentifier' を閉じています..."
        # リソースを閉じる処理
        $resource = $null
        Write-Host "リソース '$ResourceIdentifier' を閉じました。"
    } else {
         Write-Host "finally: リソースは開かれていませんでした。"
    }
}

}

Write-Host “正常終了の場合:”
Process-Resource -ResourceIdentifier “GoodResource”

Write-Host “`ntry ブロックで throw された場合:”
try {
Process-Resource -ResourceIdentifier “BadResource”
}
catch {
# Process-Resource 内の catch で捕捉されているため、ここには来ない
# Process-Resource 内で catch されずに throw された場合はここに来る
Write-Host “外部 catch でエラーを捕捉しました: $($_.Exception.Message)”
}

Write-Host “`nスクリプトは続行されています。”

catch されずにスクリプトが終了する場合も finally は実行される（可能な限り）

try { throw “Test Finally Before Exit” } finally { Write-Host “Finally before exit” }

“`

この例では、finally ブロックが try ブロックの正常終了後、または catch ブロックの実行後に実行されていることがわかります。これにより、エラーの有無にかかわらずリソースを確実にクリーンアップできます。

`throw` と `try...catch` の連携

throw キーワードと try...catch ブロックは密接に連携して動作します。throw によって発生した終了するエラーは、最も近いエンクロージングスコープ（関数、スクリプト、または現在のブロック）の try ブロックに関連付けられます。その try ブロックに続く catch ブロックが、スローされたエラーを捕捉しようとします。

もし、throw が実行された場所にそれを囲む try ブロックがない場合、または try ブロックがあっても一致する catch ブロックがない場合は、エラーは呼び出し元に伝播されます。これがスクリプトの最上位まで伝播し、それでも捕捉されない場合は、スクリプトの実行はそこで中断されます。

“`powershell

例4: throw と try…catch の連携フロー

function Divide-Numbers {
param([double]$Numerator, [double]$Denominator)

if ($Denominator -eq 0) {
    # 分母がゼロの場合は致命的なエラーとみなし、throw する
    throw "ゼロによる除算は許可されていません。"
}

# 計算結果を返す
return $Numerator / $Denominator

}

Write-Host “正常な計算:”
$result1 = Divide-Numbers -Numerator 10 -Denominator 2
Write-Host “結果: $result1”

Write-Host “`nゼロ除算 (try…catch なし):”

ここで Divide-Numbers -Denominator 0 を呼び出すと、throw されたエラーによりスクリプトが停止

Write-Host “`nゼロ除算 (try…catch あり):”
try {
Write-Host “ゼロ除算を試行中…”
$result2 = Divide-Numbers -Numerator 10 -Denominator 0
Write-Host “結果: $result2” # ここは実行されない
}
catch {
Write-Host “catch ブロックに入りました。”
Write-Host “エラーを捕捉しました: $($_.Exception.Message)”
Write-Host “ゼロによる除算エラーです。”
# エラーからの回復や代替処理を行う
$result2 = [double]::NaN # Not a Number を結果とするなど
Write-Host “結果を NaN に設定しました。”
}
finally {
Write-Host “finally ブロックに入りました。”
Write-Host “クリーンアップ処理を実行…”
}

Write-Host “`nスクリプトは続行されています。”
“`

この例では、Divide-Numbers 関数内で分母がゼロの場合に throw を使用しています。

正常な呼び出し (Divide-Numbers -Numerator 10 -Denominator 2) の場合、throw は実行されず、関数は計算結果を返します。try...catch...finally ブロックが使われていれば、try ブロック内のコードが最後まで実行され、finally ブロックが実行されます。catch ブロックは実行されません。
ゼロ除算の呼び出し (Divide-Numbers -Numerator 10 -Denominator 0) の場合、throw が実行されます。
- もしこの呼び出しが try ブロックの外で行われていれば、スクリプトはそこで直ちに停止します。
- try ブロック内で行われていれば、PowerShellは実行を中断し、対応する catch ブロックを探します。この例ではジェネリックな catch ブロックが捕捉し、そのコードが実行されます。try ブロック内の Write-Host "結果: $result2" は実行されません。その後、finally ブロックが実行され、スクリプトは try...catch...finally ブロックの後の行から実行を継続します。

この連携こそが、PowerShellにおける堅牢なエラー処理の基礎となります。問題が発生したら throw で知らせ、その知らせを try...catch で受け止めて適切に対応するという流れです。

さまざまなオブジェクトを `throw` する

前述のように、throw は文字列だけでなく、さまざまなオブジェクトをスローできます。どのようなオブジェクトをスローするかによって、catch ブロックで取得できる情報やエラー処理の柔軟性が変わってきます。

文字列を `throw` する

これは最も単純な方法で、簡単なエラーメッセージを伝えるのに適しています。

powershell throw "ユーザーが見つかりません。"

捕捉した catch ブロックの $_ 変数を見ると、$_.Exception は System.Management.Automation.RuntimeException オブジェクトであり、その Message プロパティにスローした文字列が含まれています。

powershell try { throw "これは文字列エラーです。" } catch { Write-Host "タイプ: $($_.Exception.GetType().FullName)" # System.Management.Automation.RuntimeException Write-Host "メッセージ: $($_.Exception.Message)" # これは文字列エラーです。 }

シンプルですが、エラーのタイプを区別したり、追加の構造化された情報を含めたりするには不十分です。

`System.Exception` オブジェクトを `throw` する

.NET Frameworkまたは.NET Coreには、エラーを表すための基底クラス System.Exception が用意されています。また、ファイル操作 (System.IO.IOException, System.IO.FileNotFoundException)、ネットワーク操作 (System.Net.WebException)、引数の検証 (System.ArgumentException, System.ArgumentNullException) など、特定の種類のエラーを表すための多くの派生クラスが標準で提供されています。

これらの標準の例外オブジェクトを作成して throw するのが、PowerShellにおける推奨されるエラー発生方法の一つです。

“`powershell

System.Exception オブジェクトを作成して throw

$exception = New-Object System.Exception “処理中に一般的なエラーが発生しました。”
throw $exception

標準の派生例外クラスを作成して throw

$fileNotFoundEx = New-Object System.IO.FileNotFoundException “設定ファイルが見つかりません。”, “C:\config.xml”
throw $fileNotFoundEx
“`

System.Exception およびその派生クラスは、以下のような有用なプロパティを持っています。

Message: エラーメッセージ。
StackTrace: エラーが発生したコードの呼び出し履歴。
InnerException: この例外を引き起こした元の例外（ネストされたエラーの場合）。
その他の例外固有のプロパティ（例: FileNotFoundException の FileName）。

これらのオブジェクトを throw することで、catch ブロックでエラータイプを区別し、エラーの詳細情報に構造化された方法でアクセスできます。

powershell try { # 例: 必須引数が null の場合を模倣 $arg = $null if ($arg -eq $null) { throw (New-Object System.ArgumentNullException "arg", "必須引数が指定されていません。") } } catch [System.ArgumentNullException] { Write-Host "捕捉: ArgumentNullException" Write-Host "メッセージ: $($_.Exception.Message)" Write-Host "パラメーター名: $($_.Exception.ParamName)" } catch { Write-Host "捕捉: その他のエラー" Write-Host "タイプ: $($_.Exception.GetType().FullName)" }

カスタム例外クラスを `throw` する

スクリプトやモジュールが複雑になり、独自のエラータイプを定義する必要がある場合、カスタム例外クラスを作成することができます。これにより、エラー処理のロジックをよりきめ細かく制御したり、エラーに特定の追加情報を付加したりすることが可能になります。

カスタム例外クラスは、System.Exception またはその派生クラスを継承した .NET クラスとして定義します。PowerShell内で直接C#コードを記述してコンパイルすることも可能です（Add-Type コマンドレットを使用）。

“`powershell

例5: カスタム例外クラスの使用

Add-Type を使ってインメモリで C# クラスを定義

Add-Type -TypeDefinition @’
using System;
using System.Runtime.Serialization;

// System.Exception から派生
[Serializable]
public class MyCustomException : Exception
{
public string CustomProperty { get; private set; }
public int ErrorCode { get; private set; }

public MyCustomException() : base() { }
public MyCustomException(string message) : base(message) { }
public MyCustomException(string message, Exception inner) : base(message, inner) { }

// カスタムプロパティを含むコンストラクター
public MyCustomException(string message, string customProperty, int errorCode) : base(message)
{
    CustomProperty = customProperty;
    ErrorCode = errorCode;
}

// シリアライズ対応 (PowerShell Remotingなどで必要になることがある)
protected MyCustomException(SerializationInfo info, StreamingContext context) : base(info, context)
{
    CustomProperty = info.GetString("CustomProperty");
    ErrorCode = info.GetInt32("ErrorCode");
}

// シリアライズ処理の実装
public override void GetObjectData(SerializationInfo info, StreamingContext context)
{
    base.GetObjectData(info, context);
    info.AddValue("CustomProperty", CustomProperty);
    info.AddValue("ErrorCode", ErrorCode);
}

}
‘@

カスタム例外を throw する関数

function Do-SomethingSpecific {
param([int]$InputId)

if ($InputId -lt 100) {
    $msg = "ID $InputId は無効な範囲です。"
    $customProp = "InvalidRange"
    $errorCode = 101
    # カスタム例外オブジェクトを作成して throw
    throw (New-Object MyCustomException $msg, $customProp, $errorCode)
}

Write-Host "処理成功: $InputId"

}

カスタム例外を捕捉する

try {
Write-Host “無効なIDを試行中…”
Do-SomethingSpecific -InputId 50
}
catch [MyCustomException] {
Write-Host “捕捉: カスタム例外 MyCustomException”
Write-Host “メッセージ: $($.Exception.Message)”
Write-Host “カスタムプロパティ: $($.Exception.CustomProperty)”
Write-Host “エラーコード: $($.Exception.ErrorCode)”
}
catch { # ジェネリックな catch
Write-Host “捕捉: その他のエラータイプ – $($.Exception.GetType().FullName)”
Write-Host “メッセージ: $($_.Exception.Message)”
}
“`

この例では、MyCustomException というカスタム例外クラスを定義し、それに CustomProperty と ErrorCode という独自のプロパティを追加しています。Do-SomethingSpecific 関数はこのカスタム例外を throw し、catch [MyCustomException] ブロックでその例外を捕捉し、カスタムプロパティの値にアクセスしています。

カスタム例外を使用するメリットは以下の通りです。

エラーの分類: 独自のエラータイプで問題を分類できます。
追加情報の付加: エラーに関するコンテキスト情報（エラーコード、関連するオブジェクトのIDなど）を例外オブジェクト自体に含めることができます。
処理の明確化: catch ブロックで特定のカスタム例外だけを捕捉することで、そのエラーに特化した処理ロジックを明確に記述できます。

その他のオブジェクトを `throw` する

技術的には、throw は文字列や System.Exception 以外の任意のオブジェクト（例: ハッシュテーブル、配列、カスタムPSObjectなど）をスローすることも可能です。

“`powershell

例6: ハッシュテーブルを throw (非推奨)

try {
throw @{
ErrorType = “ConfigurationError”
ErrorMessage = “設定ファイルが見つかりません”
ConfigPath = “C:\config.json”
}
}
catch {
Write-Host “捕捉: 非推奨のオブジェクト例外”
# $.Exception は RuntimeException となる
Write-Host “タイプ: $($.Exception.GetType().FullName)” # System.Management.Automation.RuntimeException
Write-Host “メッセージ: $($_.Exception.Message)” # ハッシュテーブルの文字列表現が表示されることが多い

# 元のオブジェクトを取得する方法は $_.Exception.ErrorRecord.Exception.Data など、少し複雑になる場合がある
# この方法でthrowされたオブジェクトは $_.Exception のメッセージとしては分かりにくく格納される場合がある
# 確実に取得するには $_.Exception の InnerException や Data コレクションなどを調べる必要があるが、
# これは throw されたオブジェクトの型に依存し、一貫性がない
# $_.Exception.ErrorRecord.Exception.Data に格納されることが多い
if ($_.Exception.Data.Count -gt 0) {
    Write-Host "元のオブジェクトデータ:"
    $_.Exception.Data | ForEach-Object {
         Write-Host "  $($_.Key): $($_.Value)"
    }
}

}
“`

この例のように、ハッシュテーブルを throw した場合、$_ 変数にはやはり RuntimeException を含む ErrorRecord オブジェクトが格納されます。元のハッシュテーブル自体は、$_.Exception.ErrorRecord.Exception.Data コレクションなどに格納されることがありますが、これは確実でなく、推奨される方法ではありません。

オブジェクトを throw する場合は、常に System.Exception またはその派生クラスを使用することを強く推奨します。これにより、エラー処理の標準的なパターンに従い、catch ブロックでの処理が容易かつ一貫したものになります。

エラー情報の活用

try...catch ブロックの catch ブロック内で利用できる $_ 変数（System.Management.Automation.ErrorRecord オブジェクト）には、エラーに関する非常に豊富な情報が含まれています。これらの情報を活用することで、エラーの原因を特定し、デバッグを効率化できます。

重要なプロパティを再確認し、その活用方法を具体的に見てみましょう。

$_.Exception: これは発生した元の例外オブジェクトです。このプロパティが最も重要で、エラーの核心情報を含んでいます。
- $_.Exception.Message: エラーの簡単な説明です。
- $_.Exception.GetType().FullName: 例外の完全な .NET 型名です。これにより、エラーの種類をプログラム的に判断できます。
- $_.Exception.StackTrace: エラーが発生した時点までの呼び出し履歴です。問題がどこで発生したか、どのような関数の呼び出し順序でその場所に到達したかを特定するのに役立ちます。
- $_.Exception.InnerException: 現在の例外を引き起こした別の例外がある場合に、その内部例外オブジェクトを参照します。エラーが連鎖的に発生した場合の根本原因をたどるのに有用です。
- $_.Exception.Data: 例外に関連付けられたカスタムデータを含むキー/値のコレクションです。throw されたオブジェクトによってはここに格納されることがありますが、通常は例外オブジェクト自体のプロパティとして情報を格納する方が推奨されます。
$_.InvocationInfo: エラーが発生したスクリプトまたはコマンドの実行コンテキストに関する情報です。
- $_.InvocationInfo.MyCommand.Path: エラーが発生したスクリプトファイルのパス。
- $_.InvocationInfo.ScriptContents: エラーが発生したスクリプトの内容全体。
- $_.InvocationInfo.ScriptLineNumber: エラーが発生した行の番号。
- $_.InvocationInfo.OffsetInLine: エラーが発生した行内での文字オフセット。
- $_.InvocationInfo.ScriptStackTrace: エラーが発生した時点でのスクリプトの呼び出しスタックトレース。$_.Exception.StackTrace が .NET レベルのスタックトレースであるのに対し、こちらはPowerShellスクリプトの関数呼び出しなどを追跡します。デバッグにおいて非常に役立ちます。
- $_.InvocationInfo.BoundParameters: エラーが発生したコマンドレットや関数に渡されたパラメーターとその値。
$_.CategoryInfo: エラーの分類情報です。これはコマンドレットが報告するエラーでよく使用されます。
- $_.CategoryInfo.Category: エラーのカテゴリ（例: OpenError, PermissionDenied, ObjectNotFound など）。
- $_.CategoryInfo.Activity: エラー発生時に試行されていたアクティビティ（例: Get-Content, New-Item）。
- $_.CategoryInfo.Reason: エラーの理由（例: FileNotFound, AccessDenied）。
- $_.CategoryInfo.TargetName: エラーの対象となったオブジェクトの名前（例: ファイル名、ユーザー名）。
- $_.CategoryInfo.TargetType: エラーの対象となったオブジェクトのタイプ（例: File, User）。

エラー情報の活用例:

“`powershell
try {
# 例: ファイルが見つからず、かつ読み取り権限もない状況を模倣
# throw (New-Object System.IO.FileNotFoundException “ファイルが見つかりません。”, “C:\NonExistent\SecuredFile.txt”)
# または、より具体的なエラーを throw する
throw (New-Object System.UnauthorizedAccessException “ファイルへのアクセスが拒否されました。”, (New-Object System.IO.FileNotFoundException “ファイル ‘C:\NonExistent\SecuredFile.txt’ が見つかりません。”))

# あるいは、PowerShell コマンドレットのエラーを捕捉
# Get-Content "C:\NonExistent\SecuredFile.txt" -ErrorAction Stop

}
catch {
Write-Host “— エラー詳細 —”
Write-Host “メッセージ: $($.Exception.Message)”
Write-Host “タイプ: $($.Exception.GetType().FullName)”

# InnerException があれば表示
if ($_.Exception.InnerException -ne $null) {
    Write-Host "内部エラーメッセージ: $($_.Exception.InnerException.Message)"
    Write-Host "内部エラータイプ: $($_.Exception.InnerException.GetType().FullName)"
}

Write-Host "発生箇所 (スクリプト): $($_.InvocationInfo.MyCommand.Path), 行 $($_.InvocationInfo.ScriptLineNumber)"
Write-Host "発生箇所 (スタックトレース - PS):"
Write-Host "$($_.InvocationInfo.ScriptStackTrace)"

Write-Host "発生箇所 (スタックトレース - .NET):"
Write-Host "$($_.Exception.StackTrace)"

Write-Host "エラーカテゴリ: $($_.CategoryInfo.Category)"
Write-Host "エラー理由: $($_.CategoryInfo.Reason)"
Write-Host "対象: $($_.CategoryInfo.TargetName) (タイプ: $($_.CategoryInfo.TargetType))"

Write-Host "--- エラー詳細 (終わり) ---"

# 必要に応じて、これらの情報をログファイルに書き込む
# "$((Get-Date).ToString('yyyy-MM-dd HH:mm:ss')) - ERROR - $($_.Exception.Message)" | Out-File -Path "script.log" -Append

}
“`

捕捉したエラーの詳細をこのように確認し、ログに記録することは、後から問題を分析する上で非常に重要です。特に $_.InvocationInfo.ScriptStackTrace は、エラーがスクリプト内のどの関数呼び出しを経て発生したかを追跡できるため、デバッグの際に invaluable です。

`Write-Error` と `throw` の違い

PowerShellには、エラーを報告するもう一つの主要な方法として Write-Error コマンドレットがあります。Write-Error と throw はどちらもエラーを報告しますが、その性質と使用目的には重要な違いがあります。

特徴	`Write-Error`	`throw`
エラーの種類	デフォルトは終了しないエラー (Non-terminating)	常に終了するエラー (Terminating)
実行の継続	デフォルトではスクリプトの実行が継続される	エラー発生箇所でスクリプトの実行が中断される
パイプライン	エラーを発生させた後も、パイプラインは継続される	パイプラインの処理が中断される
`try...catch`	デフォルトでは `catch` ブロックで捕捉されない (ただし `-ErrorAction Stop` を使用すると捕捉可能)	`try` ブロック内で使用した場合、`catch` ブロックで捕捉される
使用目的	軽微な問題、警告、処理続行可能な状況の報告	致命的な問題、前提条件違反、処理続行不可能な状況の報告
エラーオブジェクト	`ErrorRecord` オブジェクトをパイプラインまたはエラーデータストリームに書き出す	`System.Exception` オブジェクトまたは任意のオブジェクトを作成し、それをエラーとして「スロー」する。これは内部的に `ErrorRecord` にラップされる。

使い分けのガイドライン:

Write-Error を使う場合:
- コマンドレットや関数が、主要な処理は完了できたが、付随的な問題が発生した（例: 特定のファイルだけ処理できなかったが、他のファイルはOKだった）。
- ユーザーに特定の状況を通知したいが、スクリプト全体の停止は必要ない（例: オプションの設定ファイルが見つからなかった）。
- パイプラインでエラーを発生させたいが、パイプラインの処理自体は続けたい。
- $ErrorActionPreference や -ErrorAction を使って、エラーの扱いを呼び出し元に委ねたい（呼び出し元が -ErrorAction Stop を指定すれば中断させられる）。
throw を使う場合:
- スクリプトや関数が前提としている条件が満たされなかった（例: 必須パラメーターが指定されていない、入力値が不正で計算ができない）。
- 処理を続行することが無意味、あるいはデータ損失などのリスクがある（例: データベース接続に失敗した、重要な設定ファイルが読み込めない）。
- 特定の場所で意図的にスクリプトの実行を中断させ、try...catch ブロックによる例外処理フローに入りたい。
- カスタム例外オブジェクトを使って、エラーに構造化された情報を付加したい。

簡単に言えば、Write-Error は「これは問題ですが、続けられます」というシグナルであり、throw は「重大な問題です、これ以上続けられません」というシグナルです。

例：

“`powershell

Write-Error の例

function Get-UserByEmail {
param([string]$Email)
# ここでユーザー検索ロジック…

if ($User -eq $null) {
    # ユーザーが見つからなくても、スクリプト全体は続行可能かもしれない
    Write-Error "指定されたメールアドレス '$Email' のユーザーが見つかりませんでした。" -Category ObjectNotFound -TargetObject $Email
    return $null # 結果として null を返す
}
return $User

}

throw の例

function Update-CriticalSetting {
param([string]$SettingValue)

if ([string]::IsNullOrEmpty($SettingValue)) {
    # 設定値が必須であり、これがないと続行できない
    throw (New-Object System.ArgumentNullException "SettingValue", "設定値が必須です。")
}

# 設定更新ロジック...
Write-Host "設定を更新しました: $SettingValue"

}

— 実行例 —

Write-Host “— Get-UserByEmail —”
Get-UserByEmail -Email “[email protected]”
Write-Host “Get-UserByEmail 呼び出し後も続行”

Write-Host “`n— Update-CriticalSetting (正常) —”
Update-CriticalSetting -SettingValue “NewValue”
Write-Host “Update-CriticalSetting 呼び出し後も続行”

Write-Host “`n— Update-CriticalSetting (エラー、try…catch なし) —“

Update-CriticalSetting -SettingValue “” # ここでスクリプトが停止

Write-Host “`n— Update-CriticalSetting (エラー、try…catch あり) —”
try {
Update-CriticalSetting -SettingValue “”
}
catch [System.ArgumentNullException] {
Write-Host “捕捉: 引数エラー”
Write-Host “メッセージ: $($_.Exception.Message)”
}
catch {
Write-Host “捕捉: その他のエラー”
}
Write-Host “try…catch ブロックの後も続行”
“`

Write-Error はあくまでエラー情報を報告する「コマンド」であるのに対し、throw は現在の実行フローを中断する「ステートメント」であると理解すると、違いがより明確になります。

高度なトピック

`Trap` ステートメント

try...catch と同様に、PowerShellには Trap ステートメントというエラー処理機構も存在します。Trap は try...catch よりも古い機構で、主にスクリプトのスコープに基づいてエラーを捕捉します。

“`powershell

Trap ステートメントの例

trap {
Write-Host “Trap されました！エラータイプ: $($.Exception.GetType().FullName)”
Write-Host “メッセージ: $($.Exception.Message)”

# $_ はここでも ErrorRecord
# break # Trap 処理後、スクリプトを終了させる (デフォルトの挙動)
continue # Trap 処理後、エラーの次の行からスクリプトを継続させる

}

Write-Host “処理1”
throw “エラー1を発生” # このエラーは Trap で捕捉される
Write-Host “処理2” # Trap {continue} の場合、ここが実行される

Write-Host “処理3”
throw “エラー2を発生” # このエラーも Trap で捕捉される
Write-Host “処理4” # Trap {continue} の場合、ここが実行される

Note: try { throw … } catch { … } の中では、

catch ブロックが優先されるため Trap は実行されない。

try { throw “エラー in try” } catch { Write-Host “Catch block” }

“`

Trap ステートメントは、それが定義されたスコープ内で発生した終了するエラーを捕捉します。Trap ブロック内で break を指定すると、エラー処理後にスクリプトの実行は終了します（これがデフォルトの動作です）。continue を指定すると、エラーが発生したコマンドレットやステートメントの次の行から実行が継続されます。

try...catch は特定のコードブロックに対してエラー処理を関連付けますが、Trap はスコープ全体に適用されます。また、try...catch は特定の例外タイプを捕捉できますが、Trap はデフォルトではすべての終了するエラーを捕捉します（ただし、trap [ExceptionType] のように型を指定することも可能です）。

現代のPowerShellスクリプト開発では、柔軟性、可読性、およびエラー処理の範囲を明確にできることから、try...catch...finally が推奨される傾向にあります。Trap は主に古いスクリプトや、スクリプト全体で共通のエラー処理をシンプルに定義したい場合に利用されることがあります。しかし、複雑なエラー処理やリソース管理が必要な場合は、try...catch...finally の方が適しています。また、try...catch ブロック内で発生したエラーは、対応する catch ブロックが優先され、外側の Trap では捕捉されません。

スクリプトの中断とエラー処理

エラーによってスクリプトが中断される場合、その中断がどのように起こるかを理解することは重要です。

throw: 明示的に終了するエラーを発生させ、try...catch で捕捉されない限り実行を中断します。
-ErrorAction Stop: 終了しないエラーを終了するエラーに昇格させ、try...catch で捕捉されない限り実行を中断します。
致命的なランタイムエラー: 存在しないコマンドレットの呼び出し、ゼロ除算など、PowerShellエンジン自身が処理できないエラーは、デフォルトで終了するエラーとなり、try...catch で捕捉されない限り実行を中断します。

try...catch ブロック内でこれらの終了するエラーが発生した場合、try ブロックの残りのコードはスキップされ、PowerShellは一致する catch ブロックを探します。一致する catch が見つかればそのコードが実行され、その後 finally ブロックが実行され、スクリプトは try...catch...finally ブロックの後から続行します。一致する catch が見つからない場合は、エラーは呼び出し元に伝播し、最終的にスクリプトが中断されます。

関数やスクリプトからのエラー伝播

関数やスクリプト内で throw されたエラー、または -ErrorAction Stop やランタイムエラーで発生した終了するエラーは、それを囲む try...catch ブロックがない場合、呼び出し元に自動的に伝播されます。

“`powershell

エラーを発生させる関数

function Cause-Error {
Write-Host “Cause-Error 開始”
throw “エラー発生!” # try…catch なし
Write-Host “Cause-Error 終了” # 実行されない
}

Cause-Error を呼び出す別の関数

function Call-CauseError {
Write-Host “Call-CauseError 開始”
Cause-Error # ここで throw されたエラーが伝播してくる
Write-Host “Call-CauseError 終了” # 実行されない
}

エラーを捕捉する try…catch ブロック

try {
Write-Host “スクリプト本体開始”
Call-CauseError # ここで throw されたエラーが最終的に捕捉される
Write-Host “スクリプト本体終了” # 実行されない
}
catch {
Write-Host “スクリプト本体 catch ブロック”
Write-Host “エラーメッセージ: $($.Exception.Message)”
Write-Host “スクリプトスタックトレース: $($.InvocationInfo.ScriptStackTrace)”
}
Write-Host “スクリプト本体続行”
“`

この例では、Cause-Error 関数で throw されたエラーは、それを囲む try...catch がないため呼び出し元の Call-CauseError に伝播します。Call-CauseError にも try...catch がないため、エラーはさらに呼び出し元のスクリプト本体に伝播します。スクリプト本体には try...catch ブロックがあるため、そこでエラーが捕捉され、catch ブロックが実行されます。この伝播のおかげで、エラー処理を一箇所に集約することができます。

スタックトレース ($_.InvocationInfo.ScriptStackTrace や $_.Exception.StackTrace) は、このエラーがどの関数呼び出しを経て発生したかの情報を提供し、デバッグを助けます。

ベストプラクティス

堅牢でメンテナンス性の高いPowerShellスクリプトを書くためには、エラー処理に関するいくつかのベストプラクティスに従うことが推奨されます。

エラーメッセージは明確かつ情報豊富に:
- エラーが発生した状況、原因、可能な解決策など、ユーザーや管理者が問題を理解し解決するために必要な情報を含めるように努めます。
- throw する文字列や例外オブジェクトの Message プロパティに分かりやすいメッセージを設定します。
- 開発者向けのより詳細な情報（スタックトレース、内部エラーなど）は、ログに記録したり、Verbose ストリームに出力したりするなど、ユーザーインターフェースとは分離することを検討します。
適切な例外タイプを選択する (またはカスタム例外を作成する):
- ファイルが見つからないなら System.IO.FileNotFoundException、ネットワークエラーなら System.Net.WebException のように、エラーの内容に合致する標準の .NET 例外クラスを使用します。
- 標準の例外クラスでは表現できない独自のエラータイプや、追加の情報を含めたい場合は、カスタム例外クラスを作成します。これにより、catch ブロックでエラータイプに基づいて異なる処理を記述しやすくなります。
ジェネリックな catch は最後の手段に:
- catch { ... } のように型指定のないジェネリックな catch は、予期しないあらゆるエラーを捕捉できて便利ですが、エラータイプを特定せずに処理することになります。
- 可能な限り、catch [SpecificException] のように特定の例外タイプを捕捉するブロックを使用します。これにより、そのエラーに対して適切な処理を記述できます。
- ジェネリックな catch は、既知の例外をすべて処理した後のフォールバックとして使用し、予期しないエラーが発生したことをログに記録したり、一般的なエラーメッセージを表示したりするために利用します。
リソースのクリーンアップには finally を使用する:
- ファイルハンドル、ネットワーク接続、データベース接続、一時ファイルなど、使用後に必ず解放または削除する必要があるリソースは、finally ブロックでクリーンアップ処理を記述します。
- これにより、try ブロックでエラーが発生した場合でも、または catch ブロックでエラーを捕捉した場合でも、確実にクリーンアップが実行されます。
エラー情報をログに記録する:
- スクリプトが自動化やバックグラウンドで実行される場合、エラーメッセージがコンソールに表示されても気づかれない可能性があります。
- catch ブロック内で、発生したエラーの詳細情報（メッセージ、タイプ、スタックトレース、発生箇所など）をログファイルやイベントログに記録するようにします。これにより、後から問題を調査することが容易になります。
ユーザーへの適切なフィードバック:
- スクリプトが対話的に実行される場合、ユーザーがエラーが発生したこと、そしてそれが何を意味するのかを理解できるように、分かりやすいメッセージを表示します。
- 内部的な技術詳細は表示せず、ユーザーにとって関連性の高い情報のみを提供することが望ましい場合があります。Verbose ストリーム (Write-Verbose) を使って技術的な詳細を出力し、ユーザーが必要に応じて -Verbose パラメーターで表示できるようにするというアプローチもあります。
セキュリティに配慮する:
- ログやエラーメッセージに、機密情報や個人情報を含めないように注意します。
- スタックトレースのような詳細情報は、攻撃者にシステムの内部構造を知られるリスクがあるため、公開環境や信頼できないユーザーに対しては非表示にするか、アクセス制限されたログファイルにのみ出力するようにします。
エラー処理戦略を設計する:
- スクリプト全体として、どのような種類のエラーが発生しうるか、それぞれのエラーに対してどのように対応すべきか（続行、中断、再試行、通知など）を事前に検討し、エラー処理の設計を行います。
- 全ての可能なエラーを捕捉しようとするのは現実的ではありませんが、重要なエラーや予期されるエラーについては、適切な try...catch ブロックを用意します。

これらのベストプラクティスを実践することで、エラーが発生しても意図したとおりに動作し、問題発生時の対応が容易な、信頼性の高いPowerShellスクリプトを作成することができます。

まとめ

この記事では、PowerShellにおけるエラー処理の核心である throw キーワードと try...catch...finally ブロックについて、基本から応用までを詳細に解説しました。

PowerShellには終了しないエラーと終了するエラーの2種類があり、$ErrorActionPreference や -ErrorAction Stop によってその挙動を制御できることを学びました。

throw キーワードは、スクリプトの実行を意図的に中断させ、終了するエラーを発生させるために使用されます。これは、前提条件が満たされない場合や、それ以上の処理が不可能または危険である場合に、問題を「スロー」するための重要な手段です。文字列、標準の System.Exception オブジェクト、または独自のカスタム例外オブジェクトを throw することで、エラーに様々な情報を含めることができます。推奨されるのは、System.Exception またはその派生クラスを使用することです。

throw された終了するエラーを捕捉し、エラー発生時の処理を行うのが try...catch...finally ブロックです。try ブロックでエラーの発生可能性のあるコードを囲み、catch ブロックで特定のエラータイプや全ての終了するエラーを捕捉して処理を行います。finally ブロックは、エラーの有無にかかわらず必ず実行され、リソースのクリーンアップなどに利用されます。

catch ブロック内で利用できる $_ 変数は、発生したエラーに関する詳細な情報（例外の種類、メッセージ、スタックトレース、発生箇所など）を提供します。これらの情報を活用することで、エラーの原因究明やデバッグが効率化されます。

Write-Error はスクリプトの実行を継続する終了しないエラーを報告するために使用されるのに対し、throw は実行を中断する終了するエラーを発生させる点で根本的に異なります。どちらを使用するかは、エラーの性質とスクリプトの要件によって判断する必要があります。

また、Trap ステートメントやエラーの伝播メカニズムといった高度なトピックにも触れ、PowerShellのエラー処理体系全体への理解を深めました。

最後に、明確なエラーメッセージの提供、適切な例外タイプの使用、finally ブロックによるクリーンアップ、エラーのログ記録といったベストプラクティスを紹介しました。これらの実践は、信頼性が高くメンテナンスしやすいPowerShellスクリプトを作成する上で不可欠です。

PowerShellスクリプト開発において、エラー処理は避けて通れない課題です。throw と try...catch...finally を効果的に使いこなすことで、予期せぬ問題にも適切に対応できる、より堅牢でプロフェッショナルなスクリプトを記述できるようになるでしょう。

この記事が、あなたのPowerShellエラー処理スキルの向上に役立つことを願っています。

【PowerShell】throw によるエラー発生・例外処理の徹底解説

はじめに

PowerShellのエラーの基本

存在しないファイルに対する Get-Content (通常は終了しないエラー)

デフォルト ($ErrorActionPreference = ‘Continue’) の挙動

-ErrorAction Stop を使用して強制的に終了するエラーにする

throw キーワードとは

throw の基本的な使い方

1. 文字列を throw する

例1: シンプルな文字列を throw

try…catch で捕捉しない場合、ここでスクリプトが停止する

Check-Value -Value -5

2. オブジェクトを throw する

例2: System.Exception オブジェクトを throw

一時ファイルを作成してテスト

なぜ throw を使うのか

try...catch...finally ブロックによる例外処理

try ブロック

catch ブロック

catch の種類

捕捉したエラーの処理

finally ブロック

例3: finally ブロックによるクリーンアップ

catch されずにスクリプトが終了する場合も finally は実行される（可能な限り）

try { throw “Test Finally Before Exit” } finally { Write-Host “Finally before exit” }

throw と try...catch の連携

例4: throw と try…catch の連携フロー

ここで Divide-Numbers -Denominator 0 を呼び出すと、throw されたエラーによりスクリプトが停止

さまざまなオブジェクトを throw する

文字列を throw する

System.Exception オブジェクトを throw する

System.Exception オブジェクトを作成して throw

標準の派生例外クラスを作成して throw

カスタム例外クラスを throw する

例5: カスタム例外クラスの使用

Add-Type を使ってインメモリで C# クラスを定義

カスタム例外を throw する関数

カスタム例外を捕捉する

その他のオブジェクトを throw する

例6: ハッシュテーブルを throw (非推奨)

エラー情報の活用

Write-Error と throw の違い

Write-Error の例

throw の例

— 実行例 —

Update-CriticalSetting -SettingValue “” # ここでスクリプトが停止

高度なトピック

Trap ステートメント

Trap ステートメントの例

Note: try { throw … } catch { … } の中では、

catch ブロックが優先されるため Trap は実行されない。

try { throw “エラー in try” } catch { Write-Host “Catch block” }

スクリプトの中断とエラー処理

関数やスクリプトからのエラー伝播

エラーを発生させる関数

Cause-Error を呼び出す別の関数

エラーを捕捉する try…catch ブロック

ベストプラクティス

まとめ

コメントする 返信をキャンセル

【PowerShell】`throw` によるエラー発生・例外処理の徹底解説

`throw` キーワードとは

`throw` の基本的な使い方

1. 文字列を `throw` する

2. オブジェクトを `throw` する

なぜ `throw` を使うのか

`try...catch...finally` ブロックによる例外処理

`try` ブロック

`catch` ブロック

`catch` の種類

`finally` ブロック

`throw` と `try...catch` の連携

さまざまなオブジェクトを `throw` する

文字列を `throw` する

`System.Exception` オブジェクトを `throw` する

カスタム例外クラスを `throw` する

その他のオブジェクトを `throw` する

`Write-Error` と `throw` の違い

`Trap` ステートメント

コメントする返信をキャンセル