はい、承知いたしました。PowerShellのthrowについて、使い方とエラー処理での活用法を詳細に説明する記事を、約5000語で記述し、直接ここに表示します。

PowerShellのthrowとは？使い方とエラー処理での活用法

はじめに：PowerShellにおけるエラー処理の重要性

スクリプト開発において、エラー処理は避けて通れない重要な側面です。適切にエラー処理が施されていないスクリプトは、予期しない状況で処理が中断したり、誤った結果を出力したり、最悪の場合、システムに悪影響を与えたりする可能性があります。信頼性が高く、保守しやすいスクリプトを作成するためには、発生しうるエラーを予測し、それらに適切に対応するためのメカニズムを理解し活用することが不可欠です。

PowerShellには、エラーを検出、報告、および処理するためのいくつかのメカニズムが用意されています。主なものとしては、Write-Errorコマンドレット、try-catch-finallyブロック、trapステートメント、そして本記事の主題であるthrowステートメントなどがあります。これらのツールを適切に使い分けることで、スクリプトの堅牢性を大幅に向上させることができます。

本記事では、PowerShellのエラー処理メカニズムの中でも特に強力で、しばしば重要な役割を果たすthrowステートメントに焦点を当てます。throwがどのようなもので、どのように使用され、そしてエラー処理フレームワークの中でどのように機能するのかを、基本から応用、そしてベストプラクティスに至るまで、詳細に解説します。

PowerShellのエラーの種類：TerminateとNon-Terminate

PowerShellでは、エラーは大きく分けて二つのカテゴリに分類されます。

Non-Terminate Errors (非終了型エラー):
- これらのエラーが発生しても、スクリプトの実行は既定では継続されます。
- 最も一般的なのは、Write-Errorコマンドレットによって生成されるエラーです。
- 例えば、Get-ChildItemで存在しないファイル名を指定した場合に発生するエラーなどがこれにあたります。既定ではエラーメッセージが表示されるだけで、スクリプトの次の行の処理は継続されます。
- $ErrorActionPreference変数や-ErrorAction共通パラメータを使って、これらのエラーが発生した際のPowerShellの振る舞い（継続、問い合わせ、無視、停止など）を制御できます。
Terminate Errors (終了型エラー):
- これらのエラーが発生すると、既定では現在のスクリプト（または実行ブロック）の実行が即座に中断されます。
- throwステートメントによって生成されるエラーは、常に終了型エラーです。
- コマンドレットの内部で発生する一部の重大なエラー（例: 無効なパラメータ値で処理が続行不可能、必須リソースへのアクセス失敗など）も終了型エラーとなる場合があります。
- 終了型エラーはtry-catch-finallyブロックによって捕捉され、特別な処理を行うことができます。

throwステートメントは、意図的に終了型エラーを発生させるために使用されます。これは、スクリプトの実行中に、これ以上処理を続行できない致命的な問題が発生したと判断した場合に非常に役立ちます。例えば、必須の入力パラメータが不正な値である、依存するサービスが利用できない、予期しないシステム状態が検出された、といったシナリオで利用されます。

`throw` の基本的な使い方

throwステートメントの基本的な構文は非常にシンプルです。

powershell throw [オブジェクト]

ここで[オブジェクト]は省略可能ですが、通常はエラーに関する情報を提供するオブジェクト（文字列や例外オブジェクトなど）を指定します。このオブジェクトが、エラーメッセージやエラーレコードの元となります。

簡単な例：文字列を投げる

最もシンプルな使い方は、エラーメッセージを含む文字列をthrowの引数として指定することです。

“`powershell

スクリプトの例

$requiredSetting = $null # 何かの設定値が取得できなかったと仮定

if ($requiredSetting -eq $null) {
throw “必須設定値が取得できませんでした。処理を中断します。”
}

上記のthrowが実行されると、以下の行は実行されない

Write-Host “この行は実行されません。”
“`

このスクリプトを実行すると、ifブロック内の条件が真となり、throwステートメントが実行されます。その結果、「必須設定値が取得できませんでした。処理を中断します。」というエラーメッセージを含む終了型エラーが発生し、スクリプトの実行はそこで停止します。

この方法は手軽ですが、投げられたオブジェクトは単なる文字列として扱われるため、後述するtry-catchブロックでエラーの種類を特定したり、詳細な情報を取得したりするのには向いていません。PowerShellのエラー処理システムは、エラーオブジェクト（特にSystem.Management.Automation.ErrorRecordオブジェクト）を扱うことを前提として設計されています。そのため、より高度なエラー処理を行うには、例外オブジェクトをthrowすることが推奨されます。

簡単な例：`System.Exception` オブジェクトを投げる

PowerShellでエラーを効果的に処理するためのより良い方法は、.NETの例外クラス、特にSystem.Exceptionまたはその派生クラスのインスタンスをthrowすることです。

“`powershell

スクリプトの例

$userId = “” # ユーザーIDが空文字列だったと仮定

if ([string]::IsNullOrWhiteSpace($userId)) {
$errorMessage = “ユーザーIDは必須です。空またはホワイトスペースのみの値は許可されません。”
# System.ArgumentExceptionは、引数が不正な場合に適した例外クラス
$exception = New-Object System.ArgumentException -ArgumentList $errorMessage
throw $exception
}

Write-Host “ユーザーIDは有効です: $userId” # この行は実行されない
“`

この例では、New-Object System.ArgumentExceptionを使ってSystem.ArgumentExceptionクラスの新しいインスタンスを作成し、そのコンストラクタにエラーメッセージを渡しています。そして、この例外オブジェクトをthrowしています。

System.Exceptionやその派生クラスのオブジェクトをthrowすると、PowerShellは内部的にこのオブジェクトをラップして、よりリッチな情報を持つSystem.Management.Automation.ErrorRecordオブジェクトを作成します。このErrorRecordオブジェクトには、エラーメッセージ、エラーの種類、発生元のスクリプトファイルや行番号、スタックトレースなど、デバッグやエラー処理に役立つ様々な情報が含まれます。

throwによって発生した終了型エラーは、既定ではコンソールにエラーメッセージとスタックトレースを表示してスクリプトの実行を中断します。しかし、try-catch-finallyブロックを使用することで、この終了型エラーを捕捉し、カスタマイズされた処理を実行することが可能になります。

`throw` で投げられるオブジェクトの種類

throwステートメントは、理論的にはどのようなオブジェクトでも投げることができます。しかし、PowerShellのエラー処理システムとの連携を考えると、主に以下の種類のオブジェクトが推奨されます。

文字列 (System.String):
- 最もシンプルだが、提供できる情報が限られる。
- 単純なスクリプトや、詳細なエラー処理を必要としないケースでのみ使用するのが一般的。
- try-catchブロックで捕捉した場合、$_.ExceptionはSystem.Management.Automation.RuntimeExceptionのインスタンスとなり、そのMessageプロパティに文字列の内容が含まれます。
System.Exception またはその派生クラスのインスタンス:
- 最も推奨される方法。
- .NETの豊富な例外クラス（System.ArgumentException, System.IO.FileNotFoundException, System.InvalidOperationExceptionなど）を利用できる。
- エラーの種類を明確に伝えることができる。
- try-catchブロックで特定の例外タイプを捕捉できる。
- 例外オブジェクトには、Messageプロパティ以外にも、エラー発生時の状態を示すプロパティ（例: FileNotFoundExceptionのFileName）や、内部例外（InnerException）、スタックトレースなど、デバッグや詳細なエラー処理に役立つ多くの情報が含まれています。
System.Management.Automation.ErrorRecord のインスタンス (限定的):
- 技術的には可能ですが、throwの引数として直接ErrorRecordオブジェクトを指定することは一般的ではありません。
- 通常、ErrorRecordオブジェクトはWrite-Errorコマンドレットによって作成され、管理されます。Write-Error -ErrorAction Stopとすることで、throwと同様に終了型エラーを生成させることができます。
- throwは主にSystem.Exceptionオブジェクトを投げるために設計されていると考えるのが自然です。throwにErrorRecordオブジェクトを渡した場合、PowerShellはそれをラップして処理します。

例外クラスの利用例

.NETの例外クラスを利用することで、エラーの種類に応じた適切な処理を記述できます。よく使用される例外クラスには以下のようなものがあります。

System.ArgumentException: メソッドや関数の引数が無効な場合に発生。
System.ArgumentNullException: 引数がnullである場合に発生。
System.ArgumentOutOfRangeException: 引数の値が許容範囲外である場合に発生。
System.IO.FileNotFoundException: 指定されたファイルが見つからない場合に発生。
System.IO.DirectoryNotFoundException: 指定されたディレクトリが見つからない場合に発生。
System.InvalidOperationException: 現在のオブジェクトの状態に対してメソッド呼び出しが無効である場合に発生。
System.NotImplementedException: 求められている機能がまだ実装されていない場合に発生（開発中によく使用）。
System.UnauthorizedAccessException: 操作を実行するためのアクセス権がない場合に発生。

これらの例外クラスをインスタンス化してthrowすることで、エラーの種類を明確に伝えることができます。

“`powershell
function Get-ConfigValue {
param(
[Parameter(Mandatory=$true)]
[string]$Key,

    [string]$ConfigFile = "config.xml"
)

if (-not (Test-Path $ConfigFile)) {
    # 設定ファイルが見つからない場合はFileNotFoundExceptionを投げる
    throw New-Object System.IO.FileNotFoundException "設定ファイルが見つかりません。", $ConfigFile
    # New-Object System.IO.FileNotFoundExceptionは第二引数にファイルパスを指定できるコンストラクタを持つ
}

# ここで設定ファイルを読み込み、キーに対応する値を取得する処理を記述
# 例として、キーが見つからなかった場合を想定
$configData = @{ "DatabaseServer" = "server1"; "Timeout" = "30" } # ダミーデータ

if (-not $configData.ContainsKey($Key)) {
    # 指定されたキーが見つからない場合はArgumentExceptionを投げる
    throw New-Object System.ArgumentException "指定された設定キー '$Key' が見つかりません。", "Key"
    # System.ArgumentExceptionは第二引数にパラメータ名を指定できるコンストラクタを持つ
}

return $configData[$Key]

}

例外が発生する呼び出し

try {
Get-ConfigValue -Key “NonExistentKey” -ConfigFile “non_existent_config.xml”
}
catch [System.IO.FileNotFoundException] {
Write-Host “エラー: 設定ファイルが見つかりません。”
Write-Host “ファイルパス: $($.Exception.FileName)”
}
catch [System.ArgumentException] {
Write-Host “エラー: 無効な設定キーが指定されました。”
Write-Host “キー名: $($.Exception.ParamName)” # ArgumentException固有のプロパティ
Write-Host “メッセージ: $($.Exception.Message)”
}
catch {
# 上記以外の例外を捕捉
Write-Host “その他のエラーが発生しました: $($.Exception.Message)”
}
“`

この例では、Get-ConfigValue関数内で、ファイルが見つからない場合はSystem.IO.FileNotFoundExceptionを、指定されたキーが見つからない場合はSystem.ArgumentExceptionをそれぞれthrowしています。そして、呼び出し側ではtry-catchブロックを使って、これらの特定の例外タイプを捕捉し、それぞれに応じたエラーメッセージを表示しています。このように、適切な例外クラスをthrowすることで、エラーハンドラー側でエラーの種類を判別し、柔軟な対応が可能になります。

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

PowerShellにはthrow以外にもエラーを報告するメカニズムとしてWrite-Errorコマンドレットがあります。これらは似ているように見えますが、重要な違いがあります。

特徴	`throw`	`Write-Error`
エラーの種類	終了型エラー (Terminate Error)	非終了型エラー (Non-Terminate Error) (既定)
実行フロー	既定では、現在のスクリプト/ブロックを即時中断	既定では、スクリプトの実行を継続
補足	`try-catch`ブロックで捕捉される	`$ErrorActionPreference`または`-ErrorAction`で制御
出力	通常、エラーメッセージとスタックトレース	エラーレコードを出力ストリームに書き込む
用途	処理を続行できない致命的な問題の報告	問題を報告しつつ、処理を継続させたい場合
オブジェクト	文字列、Exceptionオブジェクトを引数に取る	ErrorRecordオブジェクトを引数に取る (通常)

実行フローへの影響

最も重要な違いは、スクリプトの実行フローへの影響です。

throwは、それが実行された時点で、現在のスクリプトや関数、またはtryブロックなどの実行を即座に中断します。これは、後続の処理を実行しても意味がない、または危険である場合に適しています。
Write-Errorは、既定ではエラーメッセージを表示するだけで、スクリプトの次の行の実行を継続します。これは、警告や、無視しても処理を進められるような問題の報告に適しています。ただし、Write-Error -ErrorAction Stopとすることで、Write-Errorでも終了型エラーを発生させ、throwと同様に実行を中断させたり、try-catchで捕捉したりすることができます。

どちらを使うべきか

どちらを使うべきかは、そのエラーが発生した状況において、スクリプトの実行を継続すべきか否かによって判断します。

throw を使用するべきケース:
- 必須の入力パラメータが欠落または無効であり、これがないと処理を続行できない場合。
- 依存するサービスやリソース（ファイル、データベース接続など）にアクセスできず、これなしでは処理を完了できない場合。
- スクリプトの実行を続けさせると、システムに不正な状態を引き起こす可能性がある場合。
- try-catchブロックでエラーを捕捉し、集中的にエラー処理を行いたい場合。
Write-Error を使用するべきケース:
- ファイルが見つからないなど、エラーが発生したが、そのエラーをスキップしても全体としての処理を継続できる場合（例: 複数のファイルを処理する際に、一部のファイルが見つからなくても残りの処理は続けたい）。
- ユーザーに警告を与えたいが、スクリプトは最後まで実行させたい場合。
- エラーをレポートするだけで、特別な例外処理は不要な場合（既定のPowerShellのエラーレポートに任せる）。
- Write-Error -ErrorAction Stop は、Write-Errorの引数としてErrorRecordオブジェクトを作成して詳細な情報を渡しつつ、終了型エラーとして扱いたい場合に有効です。特に、コマンドレットの内部でエラーを発生させる標準的な方法としてよく用いられます。

簡単に言えば、処理を続行できない致命的なエラーにはthrow、処理を継続できる非致命的なエラーや警告にはWrite-Errorを使うのが基本です。ただし、Write-Error -ErrorAction Stopを使うことで、Write-Errorを実質的にthrowと同様の終了型エラーとして扱うことも可能です。どちらを選ぶかは、開発者の意図と、エラーの詳細情報をどのように伝えたいかによります。throwはよりプログラミング的な「例外を発生させる」という意図が明確になります。

エラー処理ブロック（`try`, `catch`, `finally`）

throwステートメントによって発生した終了型エラーを捕捉し、カスタマイズされた処理を実行するためには、try-catch-finallyブロックを使用します。これは、他の多くのプログラミング言語における例外処理機構と同様のものです。

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

powershell try { # エラーが発生する可能性のあるコードをここに記述 # ここでthrowされた終了型エラーはcatchブロックで捕捉される } catch [特定の例外タイプ] { # 指定された例外タイプのエラーが発生した場合に実行されるコード # エラー情報は$_変数を通じてアクセス可能 } catch [別の特定の例外タイプ] { # 別の例外タイプの場合の処理 } catch { # 上記のどの例外タイプにも一致しないエラーが発生した場合に実行されるコード # ジェネリックなエラーハンドラ } finally { # エラーが発生したかどうかにかかわらず、常に実行されるコード # 後始末処理（ファイルハンドルの解放、ネットワーク接続の切断など）を記述 }

try ブロック:
- 監視したいコード、つまりエラーが発生する可能性のあるコードを記述します。
- このブロック内で発生した終了型エラーは、その後のcatchブロックによって捕捉されます。
- 非終了型エラーは、既定ではcatchブロックでは捕捉されません。非終了型エラーも捕捉したい場合は、tryブロック内のコードの$ErrorActionPreferenceまたは-ErrorActionをStopに設定する必要があります（例えば、Write-Error "Something bad happened" -ErrorAction Stop）。
catch ブロック:
- tryブロック内で終了型エラーが発生した場合に実行されます。
- catchキーワードの後に特定の例外タイプ（例: [System.IO.FileNotFoundException]）を指定することで、そのタイプの例外のみを捕捉できます。複数のcatchブロックを記述し、異なる例外タイプに対して異なる処理を行うことが可能です。
- 例外タイプを指定しないcatchブロックは、他のcatchブロックで捕捉されなかったすべての終了型エラーを捕捉します。これは通常、最後のcatchブロックとして配置されます。
- catchブロック内では、特殊変数$_（または$PSItem）を使用して、発生したエラーに関する情報（ErrorRecordオブジェクト）にアクセスできます。このErrorRecordオブジェクトのExceptionプロパティは、throwの引数として渡されたSystem.Exceptionオブジェクト（またはそれをラップしたオブジェクト）を提供します。
- catchブロック内で再びthrowステートメントを使用すると、捕捉したエラーを再スロー（rethrow）できます。これは、一部のエラー処理を行った後、エラーをさらに上位の呼び出し元に通知したい場合に役立ちます。単にthrowと引数なしで記述すると、現在のエラーが再スローされます。
finally ブロック:
- tryブロックの処理が完了したか、エラーが発生したかどうかにかかわらず、必ず実行されるコードを記述します。
- これは、ファイルハンドルを閉じたり、データベース接続を閉じたり、一時ファイルを削除したりするなど、リソースのクリーンアップ処理に非常に便利です。
- finallyブロックは省略可能です。

エラーオブジェクト (`$_`) の活用法

catchブロック内で利用できる特殊変数$_は、捕捉されたエラーに関する豊富な情報を持つSystem.Management.Automation.ErrorRecordオブジェクトへの参照です。このオブジェクトの最も重要なプロパティの一つはExceptionです。

$_.Exception: 発生したエラーの根本原因を示す.NETのSystem.Exceptionオブジェクトへの参照です。throwステートメントでSystem.Exceptionオブジェクトを投げた場合、このプロパティはそのオブジェクト自身を参照します。
- $_.Exception.Message: エラーメッセージ文字列。
- $_.Exception.GetType().FullName: 例外の完全修飾型名（例: “System.IO.FileNotFoundException”）。これにより、どの種類の例外が発生したかを確認できます。
- $_.Exception.StackTrace: エラーが発生したコードの呼び出し履歴（スタックトレース）。デバッグに非常に役立ちます。
- $_.Exception.InnerException: 別の例外によって発生した例外の場合、元の例外への参照。
- その他のプロパティ: 特定の例外クラスには固有のプロパティがあります（例: System.IO.FileNotFoundExceptionのFileName、System.ArgumentExceptionのParamName）。これらは$_.Exception.PropertyNameの形式でアクセスできます。
$_.InvocationInfo: エラーが発生したスクリプトやコマンドレットに関する情報（スクリプトファイル名、行番号、列番号、コマンドレット名など）。
$_.CategoryInfo: エラーのカテゴリに関する情報。
$_.TargetObject: エラーに関連するオブジェクト（例: Get-ChildItemで見つからなかったファイルの名前）。

これらの情報 ($_のプロパティ) を活用することで、エラーハンドラーはエラーの詳細をログに記録したり、ユーザーに分かりやすいメッセージを表示したり、問題の原因を特定したりすることができます。

“`powershell
function Test-TryCatchThrow {
param(
[string]$Path
)

try {
    Write-Host "Trying to access path: $Path"
    if (-not (Test-Path $Path)) {
        # パスが存在しない場合は FileNotFoundException を throw
        throw New-Object System.IO.FileNotFoundException "指定されたパスが見つかりません。", $Path
    }
    # ここにパスに対する処理を記述 (例: ファイル内容の読み込みなど)
    Write-Host "Path exists. Processing..."
    # ... 何らかの処理で別のエラーが発生する可能性 ...
    # 例:
    # $null.ToString() # NullReferenceException を発生させる
}
catch [System.IO.FileNotFoundException] {
    Write-Warning "Caught a File Not Found Exception."
    Write-Host "  Error Type: $($_.Exception.GetType().FullName)"
    Write-Host "  Message: $($_.Exception.Message)"
    Write-Host "  File Name: $($_.Exception.FileName)" # FileNotFoundException固有
    Write-Host "  Script Line: $($_.InvocationInfo.ScriptLineNumber)"
    # オプション: エラーをログに記録するなど
}
catch [System.NullReferenceException] {
    Write-Warning "Caught a Null Reference Exception."
    Write-Host "  Error Type: $($_.Exception.GetType().FullName)"
    Write-Host "  Message: $($_.Exception.Message)"
    Write-Host "  Script Line: $($_.InvocationInfo.ScriptLineNumber)"
}
catch {
    # 上記以外のすべての終了型エラーを捕捉
    Write-Error "An unexpected error occurred." -ErrorAction Continue # write-error自体はnon-terminate
    Write-Host "  Error Type: $($_.Exception.GetType().FullName)"
    Write-Host "  Message: $($_.Exception.Message)"
    Write-Host "  Stack Trace: $($_.Exception.StackTrace)" # デバッグ用
    Write-Host "  Script Line: $($_.InvocationInfo.ScriptLineNumber)"
    # オプション: エラーを再スローして呼び出し元に通知
    # throw # この行を有効にすると、このcatchブロックで捕捉したエラーを再スローする
}
finally {
    Write-Host "Finally block executed."
    # ここで後始末処理（例: 開いたファイルハンドルのクローズ）を記述
}

Write-Host "Function execution finished." # finallyブロックの後に実行される

}

存在しないパスを指定してエラーを発生させる

Test-TryCatchThrow -Path “C:\NonExistentFolder\NonExistentFile.txt”

存在する場合の例（エラーは発生しない）

Test-TryCatchThrow -Path $env:TEMP

NullReferenceExceptionを発生させる呼び出し (tryブロック内でコメントアウト解除)

Test-TryCatchThrow -Path $env:TEMP # $null.ToString()が実行されるように変更

“`

この例では、tryブロック内でTest-Pathが失敗した場合にSystem.IO.FileNotFoundExceptionをthrowしています。catch [System.IO.FileNotFoundException]ブロックはこの例外を捕捉し、エラーの詳細（ファイル名など例外固有の情報を含む）を表示します。もしtryブロック内でNullReferenceException（例: $null.ToString()）が発生した場合、二番目のcatch [System.NullReferenceException]ブロックがそれを捕捉します。それ以外の予期しない終了型エラーが発生した場合は、最後のジェネリックなcatchブロックが捕捉します。finallyブロックは、エラーが発生したかどうかにかかわらず、常に実行されます。

`throw` とエラー処理の応用例

throwステートメントは、様々なシナリオでスクリプトのロジックを明確にし、エラー処理を構造化するために活用できます。

1. 入力値の検証

関数やスクリプトのパラメータが期待される形式や範囲外の値である場合、そのパラメータを使って処理を続行することは意味がないか、あるいはエラーを引き起こす可能性が高いです。このような場合、早期に不正な入力値を検出してエラーを発生させ、スクリプトの実行を中断するのが適切です。throwは、このような入力検証のエラーを通知するのに役立ちます。

“`powershell
function Set-ServerPort {
param(
[Parameter(Mandatory=$true)]
[int]$Port
)

# ポート番号が有効な範囲にあるか検証 (例: 1-65535)
if ($Port -lt 1 -or $Port -gt 65535) {
    # 無効なポート番号の場合は ArgumentOutOfRangeException を throw
    throw New-Object System.ArgumentOutOfRangeException "Port", $Port, "ポート番号は1から65535の範囲である必要があります。"
}

Write-Host "サーバーポートを $Port に設定します。"
# ここで実際にポートを設定する処理

}

有効なポート番号

Set-ServerPort -Port 8080

無効なポート番号 (エラー発生)

try {
Set-ServerPort -Port 99999
}
catch [System.ArgumentOutOfRangeException] {
Write-Host “ポート設定エラー: $($.Exception.Message)”
Write-Host “指定された値: $($.Exception.ActualValue)” # ArgumentOutOfRangeException固有
}
“`

この例では、Set-ServerPort関数が受け取るPortパラメータの値が有効な範囲外である場合に、System.ArgumentOutOfRangeExceptionをthrowしています。これにより、不正な値で後続の処理が実行されるのを防ぎます。呼び出し側ではcatchブロックを使ってこの特定のエラータイプを捕捉し、適切なエラーメッセージを表示しています。

`ValidateScript` との組み合わせ

PowerShellのパラメータ属性であるValidateScriptとthrowを組み合わせることで、より宣言的に入力値の検証を行うことができます。ValidateScriptブロック内でthrowを使用すると、検証エラーが発生した場合にParameterBindingExceptionを生成させることができます。

“`powershell
function Set-ServerPortWithValidateScript {
param(
[Parameter(Mandatory=$true)]
[ValidateScript({
if ($ -lt 1 -or $ -gt 65535) {
# ValidateScript内でthrowを使用
throw “ポート番号 $_ は1から65535の範囲外です。”
}
$true # 検証成功時は$trueを返す
})]
[int]$Port
)

Write-Host "サーバーポートを $Port に設定します。"
# ここで実際にポートを設定する処理

}

有効なポート番号

Set-ServerPortWithValidateScript -Port 8080

無効なポート番号 (検証エラー発生)

try {
Set-ServerPortWithValidateScript -Port 99999
}
catch [System.Management.Automation.ParameterBindingException] {
Write-Host “パラメータ検証エラー: $($.Exception.Message)”
# 例外メッセージにValidationScript内でthrowした文字列が含まれる
}
catch {
Write-Host “その他のエラー: $($.Exception.Message)”
}
“`

ValidateScript内でthrowされたエラーは、PowerShellのパラメータバインディングシステムによって捕捉され、ParameterBindingExceptionとして再パッケージ化されます。このParameterBindingExceptionのメッセージには、ValidateScript内でthrowしたエラーメッセージが含まれます。この方法は、パラメータの検証ロジックをパラメータ定義自体に組み込めるため、コードの可読性が向上します。

2. 予期しない状態の検出

スクリプトの実行中に、予期していなかったが処理を続行できない重大なシステムの状態が検出されることがあります。例えば、必要な設定ファイルが破損している、外部APIからの応答が不正である、必須のプロセスが実行されていない、といった状況です。このような場合も、throwを使用してエラーを発生させ、問題を明確に報告し、スクリプトの実行を安全に中断するのが適切です。

“`powershell
function Process-Data {
param(
[string]$DataSourcePath
)

# データソースが利用可能かチェック
if (-not (Test-Path $DataSourcePath)) {
    throw New-Object System.IO.FileNotFoundException "データソース '$DataSourcePath' が見つかりません。処理を続行できません。", $DataSourcePath
}

# データソースの整合性をチェック (例: XMLファイルのルートノードが存在するか)
try {
    [xml]$data = Get-Content $DataSourcePath
    if ($data.ChildNodes.Count -eq 0) {
        # データソースが空または不正な形式の場合
         throw New-Object System.InvalidOperationException "データソース '$DataSourcePath' が空であるか、不正な形式です。"
    }
}
catch [System.Xml.XmlException] {
    # XMLパースエラーが発生した場合
    throw New-Object System.InvalidOperationException "データソース '$DataSourcePath' のXML形式が不正です。", $_.Exception
    # InnerExceptionとして元のXmlExceptionを含める
}
catch {
    # その他の読み込みエラー
    throw New-Object System.IO.IOException "データソース '$DataSourcePath' の読み込み中に予期しないエラーが発生しました。", $_.Exception
}


Write-Host "データソースを正常に読み込みました。処理を開始します。"
# データ処理ロジック ...

}

存在しないデータソースを指定

try {
Process-Data -DataSourcePath “C:\Data\source.xml”
}
catch [System.IO.FileNotFoundException] {
Write-Error “処理失敗: データソースファイルが見つかりません。” -ErrorAction Stop
}
catch [System.InvalidOperationException] {
Write-Error “処理失敗: データソースの内容に問題があります。” -ErrorAction Stop
if ($.Exception.InnerException) {
Write-Error ” 内部エラー: $($.Exception.InnerException.Message)” -ErrorAction Stop
}
}
catch [System.IO.IOException] {
Write-Error “処理失敗: データソースの読み込みエラー。” -ErrorAction Stop
if ($.Exception.InnerException) {
Write-Error ” 詳細: $($.Exception.InnerException.Message)” -ErrorAction Stop
}
}
catch {
Write-Error “予期しないエラーにより処理が中断されました。” -ErrorAction Stop
Write-Error “詳細: $($_.Exception.Message)” -ErrorAction Stop
}
“`

この例では、Process-Data関数がまずデータソースファイルが存在するか確認し、存在しない場合はFileNotFoundExceptionをthrowします。さらに、XMLとして読み込もうとしてパースエラーが発生したり、内容が空である場合など、処理を続行できない状態を検出した場合に、それぞれ適切な例外タイプ（InvalidOperationException、IOExceptionなど）をthrowしています。catch [System.Xml.XmlException]ブロックでは、パースエラーを捕捉し、それをラップしてより一般的なInvalidOperationExceptionとして再スローしています。これにより、呼び出し側ではより高レベルのエラータイプ（ファイルが見つからない、内容が不正、読み込みエラー）でエラーを捕捉できます。

3. 複雑な処理の早期終了

ネストされた関数呼び出しや深いループ構造の中でエラーが発生した場合、その場でエラー処理を行うのではなく、エラーを発生させて呼び出しスタックを遡り、適切なエラーハンドラー（通常は最上位のtry-catchブロック）でまとめて処理したい場合があります。throwステートメントは、このような「ジャンプ」を行うのに非常に効果的です。

“`powershell
function Do-StepC {
param([int]$Value)
if ($Value -lt 0) {
# ここで致命的なエラーが発生したと想定し、throw
throw New-Object System.ArgumentOutOfRangeException “Value”, $Value, “ステップCでは負の値を処理できません。”
}
Write-Host “Step C processed value: $Value”
}

function Do-StepB {
param([int]$InputValue)
Write-Host “Starting Step B with value: $InputValue”
# Do-StepCを呼び出す
Do-StepC -Value ($InputValue – 10)
Write-Host “Finished Step B.” # StepCでthrowされるとここには到達しない
}

function Do-StepA {
param([int]$InitialValue)
Write-Host “Starting Step A with value: $InitialValue”
try {
# Do-StepBを呼び出す
Do-StepB -InputValue $InitialValue
Write-Host “Finished Step A successfully.” # エラーがなければここが実行される
}
catch {
# StepBまたはStepCでthrowされたエラーを捕捉
Write-Host “Caught error in Step A handler.”
Write-Host ” Error Details: $($.Exception.Message)”
Write-Host ” Stack Trace:”
$.Exception.StackTrace # スタックトレースを表示
# throw $_.Exception # 必要ならさらに上位にエラーを再スロー
}
finally {
Write-Host “Step A finally block executed.”
}
}

エラーが発生しない呼び出し

Do-StepA -InitialValue 20

Write-Host “—“

エラーが発生する呼び出し (StepCでthrow)

Do-StepA -InitialValue 5
“`

この例では、Do-StepAがDo-StepBを呼び出し、Do-StepBがDo-StepCを呼び出しています。Do-StepC内で、入力値が負の場合にArgumentOutOfRangeExceptionがthrowされます。このthrowによって、Do-StepCの残りの処理、Do-StepBの残りの処理はスキップされ、呼び出しスタックを遡って最も近いtry-catchブロックであるDo-StepA内のcatchブロックでエラーが捕捉されます。これにより、エラーが発生した場所から、エラー処理を行うべき場所まで、コードの実行フローを効率的に移動させることができます。スタックトレースを確認すると、エラーがDo-StepCで発生し、Do-StepBを経由してDo-StepAのcatchブロックに到達したことがわかります。

4. カスタム例外の作成と利用 (発展)

標準の.NET例外クラスだけでは表現できない、アプリケーション固有のエラー状態がある場合、カスタム例外クラスを定義して使用することができます。カスタム例外クラスは、エラーの種類をより明確に分類できるだけでなく、エラーに関する追加情報を持たせるプロパティを追加することも可能です。

PowerShellでカスタム例外クラスを作成するには、Add-Typeコマンドレットを使用してC#などのコードをコンパイルするか、PowerShell 5.0以降で導入されたクラス定義構文を使用します。ここではクラス定義構文を使った簡単な例を示します。

“`powershell

PowerShell 5.0 以降で利用可能

class MyAppSpecificException : System.Exception {
# コンストラクタ
MyAppSpecificException([string]$message) : base($message) {
# 基本クラス(System.Exception)のコンストラクタを呼び出す
}

# 追加のプロパティ (例: エラーコード)
[int]$ErrorCode

# エラーコード付きのコンストラクタ
MyAppSpecificException([string]$message, [int]$errorCode) : base($message) {
    $this.ErrorCode = $errorCode
}

}

カスタム例外を使用する関数

function Process-Item {
param([string]$ItemId)

# 例: ItemId が特定の形式でない場合
if ($ItemId -notmatch "^\d{3}-\w{4}$") {
    # カスタム例外をthrow
    throw New-Object MyAppSpecificException "無効なアイテムID形式: '$ItemId'。期待される形式は XXX-YYYY です。", 101
}

# 例: アイテムが存在しない場合 (データベース検索など)
# if (-not (Get-DatabaseItem -Id $ItemId)) {
#     throw New-Object MyAppSpecificException "アイテム '$ItemId' が見つかりません。", 404
# }

Write-Host "アイテム '$ItemId' を処理中..."
# アイテム処理ロジック

}

カスタム例外を捕捉する

try {
Process-Item -ItemId “ABC-1234” # 無効な形式
}
catch [MyAppSpecificException] {
Write-Error “カスタム例外を捕捉しました！” -ErrorAction Stop
Write-Host ” エラーメッセージ: $($.Exception.Message)”
Write-Host ” エラーコード: $($.Exception.ErrorCode)” # カスタムプロパティにアクセス
}
catch {
Write-Error “予期しないエラーが発生しました: $($_.Exception.Message)” -ErrorAction Stop
}

Write-Host “—“

try {
Process-Item -ItemId “123-ABCD” # 有効な形式
Write-Host “処理成功”
}
catch [MyAppSpecificException] {
Write-Error “カスタム例外を捕捉しました！” -ErrorAction Stop
Write-Host ” エラーメッセージ: $($.Exception.Message)”
Write-Host ” エラーコード: $($.Exception.ErrorCode)”
}
catch {
Write-Error “予期しないエラーが発生しました: $($_.Exception.Message)” -ErrorAction Stop
}
“`

この例では、MyAppSpecificExceptionというカスタム例外クラスを定義し、System.Exceptionを継承しています。このクラスには、標準のMessageプロパティに加えて、アプリケーション固有のErrorCodeプロパティを追加しています。Process-Item関数では、無効なItemId形式の場合にこのカスタム例外をthrowしています。呼び出し側では、catch [MyAppSpecificException]としてこの特定の例外タイプを捕捉し、カスタムプロパティであるErrorCodeにアクセスして、エラーの種類に応じて詳細な処理を行うことができます。

カスタム例外は、特に大規模なスクリプトモジュールやアプリケーションを開発する際に、エラーハンドリングを体系化するのに非常に有効です。

`throw` を使用する際の注意点とベストプラクティス

throwは強力なツールですが、適切に使用しないとスクリプトのデバッグを困難にしたり、予期しない振る舞いを引き起こしたりする可能性があります。以下にthrowを使用する際の注意点とベストプラクティスを示します。

適切なエラーメッセージを含める:
- throwの引数として渡すオブジェクト（文字列または例外オブジェクト）には、エラーが発生した原因、状況、および可能な解決策を示す、明確で具体的な情報を含めるべきです。
- 「何かが間違っています」のような一般的なメッセージではなく、「ユーザー名が入力されていません」「設定ファイル ‘C:\config.json’ が見つかりません」のように具体的な情報を提供します。
- エラーメッセージは、ユーザーまたはエラーを調査する開発者が問題の本質を迅速に理解できるように記述します。
適切なオブジェクトを投げる (Exceptionオブジェクトを推奨):
- 可能な限り、単なる文字列ではなく、System.Exceptionまたはその派生クラスのインスタンスをthrowします。
- これにより、エラーハンドラー側でエラーの種類を判別したり、例外オブジェクトが提供する豊富な情報（スタックトレース、InnerException、例外固有のプロパティなど）を利用したりすることが可能になります。
- 適切な例外クラスがない場合は、カスタム例外を作成することも検討します。
throw と Write-Error の使い分けを明確にする:
- スクリプトの実行を中断する必要がある致命的なエラーにはthrowを使用します。
- スクリプトの実行を継続できる非致命的なエラーや警告にはWrite-Errorを使用します。
- Write-Error -ErrorAction Stopも終了型エラーを生成しますが、throwはより「例外を発生させる」という意図を明確にコードで表現できます。特に、独自の関数やスクリプトでアプリケーションレベルの例外を発生させる場合には、throwの方が自然な場合があります。コマンドレット内部でシステムエラーを発生させる標準的な方法としてはWrite-Error -ErrorAction Stopが一般的です。
try-catchブロックでエラーを捕捉し、適切に処理する:
- throwによって発生したエラーを捕捉するために、必ずtry-catch-finallyブロックを使用します。
- ジェネリックなcatchブロックだけでなく、特定の例外タイプを捕捉するcatchブロックを使用し、エラーの種類に応じた詳細な処理を記述します。
- catchブロック内では、$_変数を使ってエラー情報を取得し、ログ出力、ユーザーへの通知、リソースのクリーンアップなどの適切な処理を行います。
finallyブロックで後始末処理を行う:
- ファイルやネットワーク接続などのリソースを使用している場合、エラーが発生したかどうかに関わらず、これらのリソースが確実に解放されるように、クリーンアップ処理をfinallyブロックに記述します。
不要なthrowを避ける:
- 単なる情報提供や軽微な問題報告のためにthrowを使用すべきではありません。そのような場合はWrite-WarningやWrite-Verbose、またはWrite-Error（非終了型）を使用します。
- throwは制御フローを急に変えるため、過度に使用するとコードの追跡が難しくなる可能性があります。エラーが本当に処理を続行不能にする場合に限定して使用します。
エラーの再スロー (throw 単独):
- catchブロック内で捕捉したエラーを一部処理した後、さらに上位のハンドラーにエラーを伝えたい場合は、引数なしのthrowを使用します。これにより、元のエラーオブジェクトとスタックトレースが保持されたまま、エラーが再スローされます。
- throw $_.Exceptionのように新しいthrowを記述すると、新しいスタックトレースが開始されてしまい、元のエラー発生箇所の情報が失われる可能性があるため、エラーの再スローには引数なしのthrowを推奨します。
グローバルなエラーハンドリング $ErrorActionPreference との相互作用:
- throwによって発生した終了型エラーは、基本的に$ErrorActionPreferenceの設定に関わらず、Stop相当の振る舞いをします。これはtry-catchブロックによってのみ捕捉されます。
- 非終了型エラー（Write-Errorの既定）に対して$ErrorActionPreference = 'Stop'を設定した場合に発生する終了型エラーも、try-catchブロックで捕捉可能です。

`throw` と他のエラー処理メカニズムの連携

PowerShellにはtry-catch-finally以外にもtrapステートメントというエラー処理機構がありますが、現在ではtry-catch-finallyブロックの使用が推奨されています。trapステートメントは、エラーが発生したときに自動的に実行されるコードブロックを定義しますが、その振る舞いは複雑で、特にスコープの扱いやエラーの再開/終了の制御がtry-catchよりも直感的ではありません。

throwによって発生したエラーは、trapステートメントでも捕捉できますが、通常はtry-catchとの組み合わせの方が柔軟で分かりやすいエラー処理を記述できます。

$Error変数には、PowerShellセッションで発生した最近のエラーのコレクションが格納されます。throwによって発生した終了型エラーも、catchブロックで捕捉されずに処理が中断した場合、この$Errorコレクションに追加されます。catchブロックでエラーを捕捉し、適切に処理した場合、そのエラーが$Errorコレクションに追加されるかどうかは、catchブロックの内部での処理によります。既定では、catchブロックで捕捉されたエラーは$Errorコレクションには追加されません。しかし、catchブロック内で明示的にWrite-Error -ErrorAction Continueなどを実行すれば、$Errorにエラーレコードを追加できます。

まとめ

PowerShellのthrowステートメントは、スクリプトの実行中に処理を続行できない重大なエラーが発生した場合に、意図的に終了型エラーを発生させるための強力なメカニズムです。これにより、不正な状態での処理の継続を防ぎ、スクリプトを安全に中断させることができます。

throwは通常、文字列または.NETのSystem.Exceptionオブジェクトを引数として使用します。特にSystem.Exceptionオブジェクトやその派生クラスを使用することで、エラーの種類を明確にし、詳細な情報（メッセージ、スタックトレース、例外固有のプロパティなど）をエラーハンドラーに伝えることができます。

throwによって発生した終了型エラーは、try-catch-finallyブロックによって捕捉され、エラーの種類に応じたカスタマイズされた処理を実行することが可能です。catchブロック内では、$_変数を通じてエラーの詳細にアクセスできます。finallyブロックは、エラーの有無にかかわらず必ず実行され、リソースのクリーンアップに役立ちます。

throwは、入力値の検証エラー、予期しないシステム状態の検出、複雑な処理構造における早期終了など、様々なシナリオで活用できます。さらに、カスタム例外クラスを定義することで、アプリケーション固有のエラーをより詳細に分類し、扱うことが可能になります。

throwを使用する際は、明確なエラーメッセージを含めること、適切なオブジェクト（特にException）を投げること、そしてWrite-Errorとの使い分けを理解することが重要です。適切にthrowとtry-catch-finallyを組み合わせることで、PowerShellスクリプトの堅牢性、信頼性、保守性を大幅に向上させることができます。

エラー処理は、単にエラーメッセージを表示するだけでなく、エラー発生時のシステムの安全性を確保し、問題の原因を迅速に特定・解決するための重要な開発手法です。throwステートメントとtry-catch-finallyブロックをマスターすることは、プロフェッショナルなPowerShellスクリプト開発者にとって不可欠なスキルと言えるでしょう。

この内容で約5000語となるように記述しました。Markdown形式で直接出力しています。各セクションで具体的なコード例を多く盛り込み、理論と実践の両面から理解を深められるように努めました。
“`markdown

PowerShellのthrowとは？使い方とエラー処理での活用法

はじめに：PowerShellにおけるエラー処理の重要性

PowerShellのエラーの種類：TerminateとNon-Terminate

PowerShellでは、エラーは大きく分けて二つのカテゴリに分類されます。この分類は、エラーが発生した際のスクリプトの実行フローにどのように影響するかに基づいています。

Non-Terminate Errors (非終了型エラー):
- これらのエラーが発生しても、スクリプトの既定の実行フローは中断されず、処理は継続されます。
- 最も一般的なのは、Write-Errorコマンドレットによって生成されるエラーです。例えば、Get-ChildItemコマンドレットで存在しないファイル名を指定した場合に発生するエラーは、既定では非終了型エラーです。エラーメッセージは表示されますが、スクリプトの次の行の処理は継続されます。
- これらのエラーは、ユーザーに問題を通知するために使用されることが多いですが、スクリプト全体の処理を停止させるほどではない場合に適しています。
- 非終了型エラーの振る舞いは、$ErrorActionPreferenceという設定変数や、個々のコマンドレットに共通パラメータとして指定できる-ErrorActionパラメータを使って制御できます。例えば、-ErrorAction Stopを指定すると、通常非終了型エラーであるものが終了型エラーとして扱われ、実行が中断されるようになります。
Terminate Errors (終了型エラー):
- これらのエラーが発生すると、既定では現在のスクリプト、関数、またはスクリプトブロックの実行が即座に中断されます。これは、処理を続行することが不可能であるか、または危険であるような、より深刻な問題を示します。
- throwステートメントによって生成されるエラーは、常に終了型エラーです。throwは、開発者が明示的に「これ以上この処理は続行できない」と判断した場合に使用するものです。
- 一部のコマンドレットや内部的な操作で発生する重大なエラーも終了型エラーとなることがあります。例えば、無効なパラメータ値が指定され、コマンドレットが全く実行を開始できないような場合や、必須のリソース（例：オペレーティングシステムの機能）へのアクセスが完全に失敗した場合などです。
- 終了型エラーは、try-catch-finallyブロックという特殊な構造によって捕捉し、エラー発生時にも特定のコードを実行させることができます。これにより、エラーからの回復を試みたり、クリーンアップ処理を実行したり、エラーをログに記録したりといった、カスタマイズされたエラー処理ロジックを実装できます。

throwステートメントの主な目的は、プログラムの実行フローの中で、意図的に終了型エラーを発生させることです。これは、スクリプトが前提としている条件が満たされない場合や、処理の継続が不可能または不適切であると判断した場合に利用されます。これにより、不完全な処理結果を防ぎ、エラー発生時の状態を明確にすることができます。

`throw` の基本的な使い方

throwステートメントの基本的な構文は非常にシンプルです。

powershell throw [オブジェクト]

ここで[オブジェクト]は省略可能ですが、通常はエラーに関する情報を提供するオブジェクトを指定します。このオブジェクトが、PowerShellのエラー処理システムが生成するエラーメッセージやエラーレコードの元となります。

引数として指定できるオブジェクトの種類はいくつかありますが、最も一般的で推奨されるのは文字列または.NETの例外オブジェクトです。

簡単な例：文字列を投げる

最もシンプルで分かりやすい使い方は、エラーメッセージを文字列としてthrowの引数に指定することです。

“`powershell

スクリプトの例

$configFilePath = “C:\App\config.xml”
if (-not (Test-Path $configFilePath)) {
# 設定ファイルが見つからない場合は処理を続行できないと判断し、throw
throw “エラー: 設定ファイルが見つかりません – $configFilePath”
}

上記のthrowが実行された場合、以下の行は実行されない

Write-Host “設定ファイルを読み込みました。”
“`

このスクリプトを実行すると、Test-Pathが$falseを返す場合、ifブロック内の条件が真となり、throwステートメントが実行されます。その結果、「エラー: 設定ファイルが見つかりません – C:\App\config.xml」というメッセージを含む終了型エラーが発生し、スクリプトの実行はそこで直ちに停止します。後続のWrite-Hostコマンドは実行されません。

この方法は手軽にエラーを発生させることができますが、投げられたオブジェクトが単なる文字列であるため、PowerShellのエラー処理システムが提供する豊富な機能を十分に活用できません。特に、try-catchブロックでエラーの種類を特定したり、エラーのスタックトレースなどの詳細情報を取得したりするのには限界があります。PowerShellは、エラー処理の内部で.NETの例外オブジェクトやErrorRecordオブジェクトを扱うことを前提として設計されています。したがって、より洗練された、あるいは構造化されたエラー処理を行うには、文字列を投げるだけでは不十分な場合が多いです。

簡単な例：`System.Exception` オブジェクトを投げる

PowerShellでエラーをより効果的に処理するための推奨される方法は、.NETの例外クラス、特にSystem.Exceptionまたはその派生クラスのインスタンスをthrowすることです。これにより、エラーに型情報や詳細情報を含めることができます。

“`powershell

スクリプトの例

$serviceName = “MyRequiredService”
if (-not (Get-Service -Name $serviceName -ErrorAction SilentlyContinue)) {
$errorMessage = “必須サービス ‘$serviceName’ が実行されていません。”
# 処理を続行できないと判断し、InvalidOperationException を throw
# InvalidOperationException は、現在のオブジェクトの状態に対してメソッド呼び出しが無効な場合に適した例外クラス
$exception = New-Object System.InvalidOperationException -ArgumentList $errorMessage
throw $exception
}

Write-Host “サービス ‘$serviceName’ は実行中です。処理を継続します。” # この行は実行されない
“`

この例では、Get-Serviceで指定したサービスが見つからないか実行されていない場合に、New-Object System.InvalidOperationExceptionを使ってSystem.InvalidOperationExceptionクラスの新しいインスタンスを作成し、そのコンストラクタにエラーメッセージを渡しています。そして、この例外オブジェクトをthrowしています。

System.Exceptionやその派生クラスのオブジェクトをthrowすると、PowerShellは内部的にこのオブジェクトをラップして、より多くの情報を持つSystem.Management.Automation.ErrorRecordオブジェクトを作成します。このErrorRecordオブジェクトは、エラーメッセージ、エラーの種類（元のExceptionオブジェクトの型）、発生元のスクリプトファイルや行番号、スタックトレースなど、デバッグやエラー処理に役立つ様々な情報を含みます。

このように、単なる文字列ではなく、適切な.NET例外クラスのインスタンスをthrowすることで、エラーハンドラー側でエラーの種類に基づいて異なる処理を行ったり、エラーオブジェクトから詳細な情報を抽出したりすることが容易になります。これは、後述するtry-catchブロックと組み合わせることで、その威力を最大限に発揮します。

`throw` で投げられるオブジェクトの種類

throwステートメントは、技術的にはどのようなオブジェクトでも投げることができます。しかし、PowerShellのエラー処理システムとの連携を最適化し、捕捉側で効率的にエラーを扱うためには、特定の種類のオブジェクトを使用することが推奨されます。主に以下の種類のオブジェクトがthrowの引数として指定されます。

文字列 (System.String):
- 最もシンプルで手軽な方法です。
- 提供できる情報が単なるエラーメッセージに限られます。
- 詳細なエラータイプによる分岐や、エラーオブジェクトのプロパティへのアクセスが難しい（不可能ではないが、文字列を解析する必要があるなど煩雑になる）ため、単純なエラー報告やクイックなテストに限定して使用するのが一般的です。
- try-catchブロックで捕捉した場合、$_変数でアクセスできるErrorRecordオブジェクトのExceptionプロパティは、System.Management.Automation.RuntimeExceptionのインスタンスとなり、そのMessageプロパティに文字列の内容が含まれます。
System.Exception またはその派生クラスのインスタンス:
- 最も推奨される方法です。
- .NETフレームワークには、様々な種類のエラー状況に対応するための豊富な例外クラス階層（System.IO.FileNotFoundException, System.ArgumentException, System.InvalidOperationExceptionなど）が定義されています。これらのクラスのインスタンスをthrowすることで、エラーの種類を明確に伝えることができます。
- 例外オブジェクトは、エラーメッセージ(Message)だけでなく、エラー発生時の状態を示すプロパティ（例: FileNotFoundExceptionのFileName、ArgumentExceptionのParamName）、内部例外(InnerException)、スタックトレース(StackTrace)など、デバッグや詳細なエラー処理に役立つ多くの情報を含んでいます。
- try-catchブロックでは、特定の例外タイプを指定して捕捉できるため、エラーの種類に応じた精密なエラーハンドリングが可能になります。
その他のオブジェクト:
- 技術的にはthrowに文字列や例外オブジェクト以外のオブジェクト（例: ハッシュテーブル、カスタムオブジェクトなど）を渡すことも可能ですが、これはあまり一般的ではなく、非推奨です。
- PowerShellのエラー処理システムは、文字列またはExceptionオブジェクトを受け取った場合を想定して最適に動作するように設計されています。その他のオブジェクトを渡した場合、PowerShellはそれを文字列に変換したり、ジェネリックなRuntimeExceptionの一部としてラップしたりすることがあります。この場合、エラーハンドラー側で元のオブジェクトの情報を適切に抽出するのが困難になることがあります。
- エラーに関する情報を提供したい場合は、Exceptionオブジェクトのプロパティ（例: Dataプロパティ）やカスタム例外クラスを使用することを検討すべきです。

例外クラスの利用例

.NETの例外クラスを利用することで、エラーの種類に応じた適切な処理を記述できます。以下に、よく使用される例外クラスの一部と、それらをthrowする例を示します。

System.ArgumentException: メソッドや関数の引数が無効な場合に発生します。
- 例: throw New-Object System.ArgumentException "無効な引数です。", "ParameterName"
System.ArgumentNullException: 必須の引数がnullである場合に発生します。
- 例: $paramValue = $null; if ($paramValue -eq $null) { throw New-Object System.ArgumentNullException "ParameterName" }
System.ArgumentOutOfRangeException: 引数の値が許容範囲外である場合に発生します。
- 例: $port = 99999; if ($port -lt 1 -or $port -gt 65535) { throw New-Object System.ArgumentOutOfRangeException "Port", $port, "ポート番号は1から65535の範囲外です。" }
System.IO.FileNotFoundException: 指定されたファイルが見つからない場合に発生します。
- 例: $filePath = "C:\nonexistent.txt"; if (-not (Test-Path $filePath)) { throw New-Object System.IO.FileNotFoundException "ファイルが見つかりません。", $filePath }
System.IO.DirectoryNotFoundException: 指定されたディレクトリが見つからない場合に発生します。
- 例: $dirPath = "C:\nonexistent_dir"; if (-not (Test-Path $dirPath -PathType Container)) { throw New-Object System.IO.DirectoryNotFoundException "ディレクトリが見つかりません。", $dirPath }
System.InvalidOperationException: 現在のオブジェクトやシステムの状態では、要求された操作を実行できない場合に発生します。
- 例: throw New-Object System.InvalidOperationException "サービスが開始されていないため、操作を実行できません。"
System.NotImplementedException: 呼び出されたメソッドや機能が、まだ実装されていない場合に発生します。主に開発中のプレースホルダーとして使用されます。
- 例: throw New-Object System.NotImplementedException "この機能はまだ実装されていません。"
System.UnauthorizedAccessException: 操作を実行するために必要な権限がない場合に発生します。
- 例: throw New-Object System.UnauthorizedAccessException "ファイルへの書き込み権限がありません。"

これらの例外クラスをインスタンス化してthrowすることで、エラーの種類を明確に伝えることができます。そして、呼び出し側のtry-catchブロックで、これらの特定の例外タイプを捕捉し、それぞれに応じた固有のエラー処理（例：FileNotFoundExceptionの場合はファイルパスをログに記録、ArgumentOutOfRangeExceptionの場合は許容範囲を示すメッセージを表示）を記述することが可能になります。これは、エラーハンドリングの精度と可読性を高めます。

“`powershell
function Get-ConfigurationValue {
param(
[Parameter(Mandatory=$true)]
[string]$Key,

    [string]$ConfigFile = "config.json"
)

# 1. 設定ファイルが存在するか確認
if (-not (Test-Path $ConfigFile)) {
    # ファイルが見つからない場合は FileNotFoundException を throw
    # 第二引数はファイルパスを表す
    throw New-Object System.IO.FileNotFoundException "設定ファイルが見つかりません。", $ConfigFile
}

# 2. 設定ファイルを読み込み、パースする（エラーチェックを含む）
try {
    # ここではダミーとしてハッシュテーブルを使用
    # 実際には ConvertFrom-Json や XMLの読み込みなど
    $configData = @{
        "DatabaseServer" = "db.example.com";
        "TimeoutSeconds" = 60;
        "UseCaching" = $true
    }
    # 何らかのパースエラーが発生する可能性がある場合を想定
    # throw New-Object System.Text.Json.JsonException "JSONパースエラーが発生しました。"
}
catch [System.Text.Json.JsonException] { # 例: JSONパースエラー
    # パースエラーの場合は InvalidDataException を throw し直す（元の例外をInnerExceptionとして含める）
    throw New-Object System.IO.InvalidDataException "設定ファイル '$ConfigFile' の形式が不正です。", $_.Exception
}
catch { # その他のファイル読み込み中のIOエラーなど
    throw New-Object System.IO.IOException "設定ファイル '$ConfigFile' の読み込み中にエラーが発生しました。", $_.Exception
}


# 3. 指定されたキーが存在するか確認
if (-not $configData.ContainsKey($Key)) {
    # キーが見つからない場合は ArgumentException を throw
    # 第二引数はパラメータ名を表す
    throw New-Object System.ArgumentException "指定された設定キー '$Key' が設定ファイルに見つかりません。", "Key"
}

# 4. キーに対応する値を返す
return $configData[$Key]

}

Get-ConfigurationValue 関数を呼び出し、try-catchでエラーを捕捉

try {
# 存在しないファイルを指定して FileNotFoundException を発生させる
# $value = Get-ConfigurationValue -Key “DatabaseServer” -ConfigFile “non_existent_config.json”

# 存在しないキーを指定して ArgumentException を発生させる
$value = Get-ConfigurationValue -Key "NonExistentKey" -ConfigFile "config.json"

# 成功した場合
Write-Host "設定値を取得しました: $value"

}
catch [System.IO.FileNotFoundException] {
Write-Error “処理失敗: 設定ファイルが見つかりません。” -ErrorAction Continue
Write-Host ” 詳細: $($.Exception.Message)”
Write-Host ” ファイルパス: $($.Exception.FileName)” # FileNotFoundException固有プロパティ
}
catch [System.ArgumentException] {
Write-Error “処理失敗: 指定された設定キーが見つかりません。” -ErrorAction Continue
Write-Host ” 詳細: $($.Exception.Message)”
Write-Host ” キー名: $($.Exception.ParamName)” # ArgumentException固有プロパティ
}
catch [System.IO.InvalidDataException] {
Write-Error “処理失敗: 設定ファイルのデータ形式が不正です。” -ErrorAction Continue
Write-Host ” 詳細: $($.Exception.Message)”
if ($.Exception.InnerException) {
Write-Host ” 元のエラー: $($.Exception.InnerException.Message)”
}
}
catch [System.IO.IOException] {
Write-Error “処理失敗: 設定ファイルの読み込み中にIOエラーが発生しました。” -ErrorAction Continue
Write-Host ” 詳細: $($.Exception.Message)”
if ($.Exception.InnerException) {
Write-Host ” 元のエラー: $($.Exception.InnerException.Message)”
}
}
catch {
# 上記以外のすべての終了型エラーを捕捉
Write-Error “予期しないエラーにより処理が中断されました。” -ErrorAction Continue
Write-Host ” エラータイプ: $($.Exception.GetType().FullName)”
Write-Host ” エラーメッセージ: $($.Exception.Message)”
Write-Host ” 発生箇所: $($_.InvocationInfo.ScriptStackTrace)” # スタックトレース表示
}
finally {
Write-Host “設定値取得処理が完了しました（エラーの有無に関わらず）。”
}
“`

この例では、Get-ConfigurationValue関数内で、ファイルが存在しない、キーが見つからない、またはファイルの内容に問題があるといった異なるエラー状況に対して、それぞれ適切な.NET例外クラス（FileNotFoundException、ArgumentException、InvalidDataException、IOException）をthrowしています。呼び出し側では、複数のcatchブロックを使ってこれらの特定の例外タイプを捕捉し、それぞれに応じたエラーメッセージや詳細（例外固有のプロパティを含む）を表示しています。このように、エラーの種類ごとに異なる処理を記述できる点が、Exceptionオブジェクトをthrowする大きなメリットです。また、InvalidDataExceptionやIOExceptionをthrowする際に、元のパースエラー(JsonException)をInnerExceptionとして含めている点も、エラー発生の連鎖を記録しておく上で重要なテクニックです。

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

PowerShellにはthrow以外にもエラーを報告するメカニズムとしてWrite-Errorコマンドレットがあります。これらは似ているように見えますが、スクリプトの実行フロー制御という点で重要な違いがあります。

特徴	`throw`	`Write-Error`
エラーの種類	終了型エラー (Terminate Error)	非終了型エラー (Non-Terminate Error) (既定)
実行フロー	既定では、現在のスクリプト/ブロックを即時中断	既定では、スクリプトの実行を継続
補足	`try-catch`ブロックで捕捉される	`$ErrorActionPreference`または`-ErrorAction`で制御
出力	通常、エラーメッセージとスタックトレース	エラーレコードを出力ストリームに書き込む
用途	処理を続行できない致命的な問題の報告	問題を報告しつつ、処理を継続させたい場合
オブジェクト	文字列、Exceptionオブジェクトを引数に取る	ErrorRecordオブジェクトを引数に取る (通常)
カスタム性	簡単にカスタムメッセージやExceptionを投げられる	Write-Error -ErrorRecordを使用すると詳細なカスタムエラーを作成できる

実行フローへの影響

最も根本的で重要な違いは、スクリプトの実行フローに対する影響です。

throwは、それが実行された時点で、現在のスクリプト、関数、またはtryブロックなどの実行を即座に中断します。例外が発生した行から後のコードは、catchブロックまたはfinallyブロックにジャンプしない限り実行されません。これは、後続の処理を実行しても意味がない、あるいはシステムに不正な状態を引き起こす可能性があるような、回復不能なエラーが発生した場合に適しています。
Write-Errorは、既定ではエラーメッセージを標準エラー出力ストリームに書き込むだけで、スクリプトの次の行の実行を継続します。これは、警告として問題を報告したり、エラーが発生した部分をスキップしても全体としての処理を継続できるような場合に適しています。
ただし、Write-Errorコマンドレットに-ErrorAction Stopという共通パラメータを付けて実行した場合、そのWrite-Errorは非終了型エラーではなく終了型エラーを生成するようになります。この場合、Write-Errorはthrowと同様に実行を中断させ、try-catchブロックで捕捉されるようになります。

ErrorRecordオブジェクト

Write-Errorコマンドレットは、出力ストリームにSystem.Management.Automation.ErrorRecordオブジェクトを書き込みます。このErrorRecordオブジェクトは、PowerShellのエラー処理システムの中核をなすものであり、エラーに関する豊富な情報（メッセージ、カテゴリ、発生元のオブジェクト、InvocationInfoなど）を含んでいます。Write-Errorを使うことで、このErrorRecordオブジェクトの様々なプロパティを設定して、詳細なカスタムエラーを報告することができます。

一方、throwステートメントは、引数として渡された文字列やExceptionオブジェクトを元に、PowerShellの内部でErrorRecordオブジェクトを生成します。Exceptionオブジェクトを投げた場合、生成されるErrorRecordのExceptionプロパティは、投げられたExceptionオブジェクト自身を参照します。

どちらを使うべきか

どちらのメカニズムを使うべきかは、エラーが発生した状況において、スクリプトの実行を継続すべきか、それとも直ちに中断すべきか、そしてエラーに関する情報をどのように伝えたいかによって判断します。

throw を使用するべきケース:
- スクリプトまたは関数の前提条件が満たされず、これ以上処理を続行しても無意味または危険な場合（例: 必須パラメータが欠落、依存サービス停止、アクセス権不足）。
- エラーが致命的であり、回復の見込みがない、または回復処理が複雑でtry-catchブロックによる集中管理が必要な場合。
- 特定の種類の.NET例外を発生させ、try-catchブロックでそのタイプを捕捉してエラーの種類に応じた詳細な処理を行いたい場合。
- ネストされた呼び出しの深いレベルで発生したエラーを、呼び出しスタックを遡って最上位のtry-catchハンドラーに届けたい場合。
Write-Error を使用するべきケース (既定の非終了型):
- エラーが発生したが、それが全体的な処理に致命的な影響を与えず、スクリプトの実行を継続できる場合（例: 処理対象のファイルの一部が見つからないが、残りのファイルは処理したい）。
- ユーザーに問題を通知したいが、スクリプトを中断する必要はない場合（警告に近い）。
- PowerShellの既定のエラー表示メカニズムにエラー報告を任せたい場合。
Write-Error -ErrorAction Stop を使用するべきケース:
- Write-Errorが提供するErrorRecordオブジェクトの詳細な情報設定機能（カテゴリ、ターゲットオブジェクトなど）を活用したいが、同時にエラー発生時に実行を中断させ、try-catchで捕捉したい場合。これは、コマンドレット内部で標準的なエラーを発生させる場合によく用いられます。例えば、独自のコマンドレットを作成する際に、検証エラーや処理エラーを報告するためにWrite-Error -ErrorAction Stopを使用するのが標準的な方法です。

簡単にまとめると、処理を続行できない致命的なエラーにはthrow、処理を継続できる非致命的なエラーや警告にはWrite-Error (既定)を使うのが基本です。詳細なErrorRecordをカスタマイズしつつ終了型エラーを発生させたい場合は、Write-Error -ErrorAction Stop を検討します。throwはよりプログラミング的な「例外を発生させる」という意図を明確に示す場合に適しています。

エラー処理ブロック（`try`, `catch`, `finally`）

throwステートメントによって発生した終了型エラーを捕捉し、スクリプトの実行を中断させずに、あるいは中断させた上で特定のカスタマイズされた処理を実行するためには、try-catch-finallyブロックを使用します。これは、C#, Java, Pythonなど、他の多くのプログラミング言語における例外処理機構と同様のものです。PowerShellにおけるtry-catch-finallyは、終了型エラー（Terminate Errors）を捕捉するために設計されています。

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

powershell try { # エラーが発生する可能性のあるコードをここに記述します。 # ここで発生した「終了型エラー」は、後続のcatchブロックで捕捉されます。 # 非終了型エラーは、既定ではcatchブロックでは捕捉されません。 # 非終了型エラーも捕捉したい場合は、Write-Error -ErrorAction Stop のように明示的に終了型にするか、 # tryブロック全体または特定のコマンドレットに対して -ErrorAction Stop を適用する必要があります。 } catch [特定の例外タイプ] { # tryブロック内で指定された例外タイプのエラーが発生した場合に実行されるコードです。 # 例外情報は$_変数を通じてアクセス可能です。 # このブロックが実行された後、エラーは「処理された」と見なされ、スクリプトは通常、 # catchブロックの直後のコード（finallyブロックがあればその後に）から実行を再開します。 } catch [別の特定の例外タイプ] { # 別の例外タイプの場合の処理を記述します。 # 複数のcatchブロックを記述することで、異なる種類のエラーに個別に対応できます。 # 例外タイプの指定は、最も具体的なものから順に記述するのがベストプラクティスです。 } catch { # 上記のどの例外タイプにも一致しない終了型エラーが発生した場合に実行されるコードです。 # これは「ジェネリックな」エラーハンドラとして機能し、通常は最も最後に配置します。 # エラー情報は$_変数を通じてアクセス可能です。 } finally { # tryブロックの処理が成功したか、catchブロックでエラーが捕捉されたか、 # または捕捉されないエラーが発生したかどうかにかかわらず、常に実行されるコードです。 # ファイルハンドルの解放、ネットワーク接続の切断、一時ファイルの削除など、 # リソースのクリーンアップ処理を記述するのに適しています。 }

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

try ブロック:
- ここには、エラーが発生する可能性のあるコード、つまり監視対象のコードを記述します。例えば、ファイル操作、ネットワーク通信、外部プログラムの実行、計算処理などが含まれます。
- tryブロック内でthrowステートメントが実行されると、その時点でtryブロックの残りのコードはスキップされ、対応するcatchブロック（もしあれば）に制御が移ります。
- コマンドレットによって生成された終了型エラー（例: Get-Item non_existent_file -ErrorAction Stop）もtryブロック内で発生した場合、catchブロックで捕捉されます。
- 重要な点として、既定ではWrite-Errorによって生成される非終了型エラーはtry-catchブロックでは捕捉されません。非終了型エラーをcatchで捕捉したい場合は、そのエラーを発生させるコマンドレットに対して-ErrorAction Stopを指定するか、$ErrorActionPreference = 'Stop'を一時的に設定してその範囲で実行する必要があります。
catch ブロック:
- tryブロック内で終了型エラーが発生した場合に実行されます。
- catchキーワードの後に角括弧[]で囲んで特定の例外タイプ（例: [System.IO.FileNotFoundException]、[System.ArgumentException]）を指定することで、そのタイプの例外のみを捕捉できます。これにより、エラーの種類に応じたきめ細やかな処理が可能になります。特定の例外タイプを指定するcatchブロックは、より具体的な例外タイプから順に記述するのが推奨されます（例: System.IO.FileNotFoundExceptionはSystem.IO.IOExceptionの派生クラスなので、FileNotFoundExceptionを先に捕捉しないと、IOExceptionのcatchブロックで捕捉されてしまう可能性があります）。
- 例外タイプを指定しないcatchブロックは、他のcatchブロックで捕捉されなかったすべての終了型エラーを捕捉します。これは「デフォルトの」または「ジェネリックな」エラーハンドラとして機能し、通常は複数のcatchブロックの最後に配置されます。
- catchブロック内では、特殊変数$_（または$PSItem）を使用して、発生したエラーに関する情報を持つSystem.Management.Automation.ErrorRecordオブジェクトにアクセスできます。このオブジェクトには、エラーメッセージ、エラータイプ、スタックトレース、発生箇所などの情報が含まれています。このErrorRecordオブジェクトの最も重要なプロパティの一つがExceptionプロパティであり、これはthrowの引数として渡された.NETExceptionオブジェクト（またはそれをラップしたRuntimeExceptionなど）を参照します。
- catchブロックが正常に完了すると、エラーは「処理された」と見なされ、スクリプトはcatchブロックの直後のコード（finallyブロックがあれば、その後に）から実行を再開します。
- catchブロック内で再びthrowステートメント（引数なし）を使用すると、捕捉したエラーを再スロー（rethrow）できます。これは、一部のエラー処理（例: ログ記録）を行った後、エラーをさらに上位の呼び出し元に通知したい場合に役立ちます。
finally ブロック:
- tryブロックの処理が正常に完了した場合、catchブロックでエラーが捕捉された場合、あるいはtryブロック内で捕捉されない終了型エラーが発生した場合（その場合、finallyブロックの後にスクリプトは終了します）など、エラーの有無に関わらず、常に実行されるコードを記述します。
- これは、開いたファイルハンドルやネットワーク接続などのリソースを確実に解放するためのクリーンアップ処理に非常に便利です。これにより、エラーが発生した場合でもリソースリークを防ぐことができます。
- finallyブロックは省略可能です。また、catchブロックとfinallyブロックは両方記述する必要はなく、どちらか一方または両方を省略することも可能です（ただし、tryブロックは必須です）。

`$_` 変数（ErrorRecord）の詳細

catchブロック内で使用できる特殊変数$_は、発生したエラーに関する豊富な情報を含むSystem.Management.Automation.ErrorRecordオブジェクトへの参照です。このオブジェクトのプロパティを調査することで、エラーの詳細を把握し、適切な対応を取ることができます。

主要なプロパティ：

$_.Exception: 発生したエラーの根本原因を示す.NETのSystem.Exceptionオブジェクトまたはその派生クラスのインスタンスです。throwステートメントで特定のExceptionオブジェクトを投げた場合、このプロパティはそのオブジェクト自身を参照します。
- $_.Exception.Message: エラーメッセージの文字列。通常、throwの引数として指定したメッセージです。
- $_.Exception.GetType().FullName: 例外の完全修飾型名（例: “System.IO.FileNotFoundException”）。これにより、プログラム的にエラーの種類を判断できます。
- $_.Exception.StackTrace: エラーが発生したコードの呼び出し履歴（スタックトレース）。エラー発生箇所とその呼び出しパスを特定するのに非常に役立ちます。デバッグ時に重要です。
- $_.Exception.InnerException: 別の例外によって発生した例外の場合、元の（内側の）例外への参照です。エラーの連鎖を追跡するのに使用されます。
- カスタムプロパティ: 特定のException派生クラスには固有のプロパティが含まれる場合があります（例: System.IO.FileNotFoundExceptionのFileName、System.ArgumentExceptionのParamName）。これらには$_.Exception.PropertyNameの形式でアクセスできます。
$_.InvocationInfo: エラーが発生したPowerShellの実行コンテキストに関する情報。
- $_.InvocationInfo.ScriptName: エラーが発生したスクリプトファイルのパス。
- $_.InvocationInfo.ScriptLineNumber: エラーが発生したスクリプト内の行番号。
- $_.InvocationInfo.OffsetInLine: エラーが発生した行内の列番号。
- $_.InvocationInfo.ScriptNameやScriptLineNumberは、特にデバッグ時にエラーの発生元を特定するのに非常に役立ちます。
$_.CategoryInfo: エラーのカテゴリに関する情報（例: NotSpecified, OpenError, ReadErrorなど）。
$_.TargetObject: エラーに関連するオブジェクト（例: Get-ChildItemで存在しなかったファイルの名前）。

これらの情報（特に$_.Exceptionと$_.InvocationInfo）をcatchブロックで活用することで、エラー発生時の状況を詳細に把握し、ユーザーへの適切なフィードバック、ログ記録、代替処理の実行、またはエラーからの回復といった処理を実装できます。

“`powershell
function Process-ImportantFile {
param(
[Parameter(Mandatory=$true)]
[string]$FilePath
)

try {
    Write-Host "Processing file: $FilePath"

    # 1. ファイルが存在するかチェック
    if (-not (Test-Path $FilePath)) {
        # ファイルが見つからない場合は FileNotFoundException を throw
        throw New-Object System.IO.FileNotFoundException "指定されたファイルが見つかりません。", $FilePath
    }

    # 2. ファイルを読み込む
    # 例として、読み込み時にエラーが発生する可能性をシミュレート
    # throw New-Object System.IO.IOException "ファイル読み込み中にアクセス拒否エラーが発生しました。"

    $content = Get-Content $FilePath -ErrorAction Stop # Get-Content自体のエラーも捕捉対象に

    # 3. ファイルの内容を処理する（例として、特定キーワードのチェック）
    if ($content -notmatch "START_PROCESSING") {
        # 内容に問題がある場合は InvalidDataException を throw
         throw New-Object System.IO.InvalidDataException "ファイル '$FilePath' の内容が不正です。必須キーワード 'START_PROCESSING' が見つかりません。"
    }

    Write-Host "File processed successfully."
    # 成功した場合の処理...
}
catch [System.IO.FileNotFoundException] {
    Write-Warning "Caught: File Not Found Exception."
    Write-Host "  エラー詳細: $($_.Exception.Message)"
    Write-Host "  ファイル名: $($_.Exception.FileName)" # FileNotFoundException固有
    Write-Host "  発生スクリプト: $($_.InvocationInfo.ScriptName)"
    Write-Host "  発生行番号: $($_.InvocationInfo.ScriptLineNumber)"
    # 例: ユーザーにファイルの場所を確認するよう促す、別のデフォルトファイルを探すなど
    # throw # エラーを再スロー
}
catch [System.IO.IOException] {
     Write-Warning "Caught: IO Exception during file processing."
     Write-Host "  エラー詳細: $($_.Exception.Message)"
     Write-Host "  発生スクリプト: $($_.InvocationInfo.ScriptName)"
     Write-Host "  発生行番号: $($_.InvocationInfo.ScriptLineNumber)"
     # 例: アクセス権を確認するようユーザーに通知するなど
     # throw # エラーを再スロー
}
catch [System.IO.InvalidDataException] {
    Write-Warning "Caught: Invalid Data Exception."
    Write-Host "  エラー詳細: $($_.Exception.Message)"
    Write-Host "  発生スクリプト: $($_.InvocationInfo.ScriptName)"
    Write-Host "  発生行番号: $($_.InvocationInfo.ScriptLineNumber)"
    # 例: ファイルの内容を確認するようユーザーに通知するなど
}
catch {
    # 上記以外のすべての終了型エラーを捕捉（例: Get-Content 自体の他のエラーなど）
    Write-Error "An unexpected error occurred during file processing." -ErrorAction Continue
    Write-Host "  エラータイプ: $($_.Exception.GetType().FullName)"
    Write-Host "  エラーメッセージ: $($_.Exception.Message)"
    Write-Host "  スタックトレース: $($_.Exception.StackTrace)" # デバッグ用
    Write-Host "  発生スクリプト: $($_.InvocationInfo.ScriptName)"
    Write-Host "  発生行番号: $($_.InvocationInfo.ScriptLineNumber)"
    # エラーをログに記録したり、システム管理者に通知したりするなど
    # throw # エラーを再スロー
}
finally {
    Write-Host "Finished attempting to process file: $FilePath"
    # ここで開いたファイルハンドルのクローズなど後始末処理を記述
    # 例: if ($fileHandle) { $fileHandle.Close() }
}

Write-Host "Function execution completed." # catchブロックでエラーを処理した場合、ここまで到達する

}

存在しないファイルを指定してエラーを発生させる

Write-Host “n--- Testing File Not Found Error ---n”
Process-ImportantFile -FilePath “C:\This\Path\Does\Not\Exist\MyDataFile.txt”

内容が不正なファイルを指定してエラーを発生させる（一時ファイルを作成）

Write-Host “n--- Testing Invalid Data Error ---n”
$invalidFile = Join-Path ([System.IO.Path]::GetTempPath()) “InvalidDataFile.txt”
“This file does not contain the required keyword.” | Out-File $invalidFile
try {
Process-ImportantFile -FilePath $invalidFile
} finally {
Remove-Item $invalidFile -ErrorAction SilentlyContinue
}

読み込みエラーをシミュレート（tryブロック内でコメントアウト解除してテスト）

Write-Host “`n--- Testing IO Error ---`n”

Process-ImportantFile -FilePath “C:\valid_but_access_denied.txt” # このファイルは実際には存在しなくても良い、シミュレーションなので

成功する例（一時ファイルを作成）

Write-Host “n--- Testing Success Case ---n”
$validFile = Join-Path ([System.IO.Path]::GetTempPath()) “ValidDataFile.txt”
“This file contains the required keyword.” | Out-File $validFile
“START_PROCESSING” | Out-File $validFile -Append
try {
Process-ImportantFile -FilePath $validFile
} finally {
Remove-Item $validFile -ErrorAction SilentlyContinue
}
“`

この包括的な例では、Process-ImportantFile関数内で、ファイルの存在チェック、読み込み、内容チェックといった処理において発生しうる異なる種類のエラー（FileNotFoundException、IOException、InvalidDataExceptionなど）を想定し、それぞれに対してthrowを使用して終了型エラーを発生させています。関数の呼び出し側では、try-catch-finallyブロックを使ってこれらのエラーを捕捉しています。複数のcatchブロックを使い分けることで、エラーの種類に応じた具体的なエラーメッセージや追加情報（ファイル名、発生行など）を表示しています。最後のジェネリックなcatchブロックは、予期しない他のエラーを捕捉します。finallyブロックは、エラーの有無に関わらず実行され、後始末処理を行う場所として示されています。この例は、throwとtry-catchを組み合わせることで、いかに詳細で構造化されたエラー処理を実装できるかを示しています。

`throw` とエラー処理の応用例

throwステートメントは、様々なシナリオでスクリプトのロジックを明確にし、エラー処理を構造化するために非常に効果的に活用できます。

1. 入力値の検証

関数やスクリプトのパラメータが期待される形式や範囲外の値である場合、そのパラメータを使って処理を続行することは意味がないか、あるいはエラーを引き起こす可能性が高いです。このような場合、入力検証の早い段階で不正な値を検出してエラーを発生させ、スクリプトの実行を中断するのが適切です。throwは、このような入力検証のエラーを明確に通知するのに役立ちます。特に、必須のパラメータが欠落している場合や、パラメータの値が有効な選択肢のリストに含まれていない場合などに使用されます。

“`powershell
function Process-UserAccount {
param(
[Parameter(Mandatory=$true)]
[string]$UserName,

    [Parameter(Mandatory=$true)]
    [string]$Role # 'Admin', 'User', 'Guest' のいずれかを期待
)

# UserName が空またはホワイトスペースのみでないか検証
if ([string]::IsNullOrWhiteSpace($UserName)) {
    # ArgumentNullException を throw
    throw New-Object System.ArgumentNullException "UserName", "ユーザー名は必須です。空またはホワイトスペースのみの値は許可されません。"
}

# Role が期待される値のいずれかであるか検証
$validRoles = @('Admin', 'User', 'Guest')
if ($Role -notin $validRoles) {
    # ArgumentException を throw (引数自体は存在したが値が無効な場合)
    throw New-Object System.ArgumentException "無効なロール '$Role' が指定されました。ロールは $($validRoles -join ', ') のいずれかである必要があります。", "Role"
}

Write-Host "ユーザー '$UserName' をロール '$Role' で処理します。"
# ここでユーザーアカウントに関する処理を記述...

}

有効な入力

Process-UserAccount -UserName “Alice” -Role “Admin”

Write-Host “n--- Testing Invalid Input ---n”

無効な入力 (Role)

try {
Process-UserAccount -UserName “Bob” -Role “Editor”
}
catch [System.ArgumentException] {
Write-Error “パラメータエラー: $($.Exception.Message)” -ErrorAction Continue
Write-Host ” 対象パラメータ: $($.Exception.ParamName)” # ArgumentException固有プロパティ
}
catch [System.ArgumentNullException] {
Write-Error “パラメータエラー: $($.Exception.Message)” -ErrorAction Continue
Write-Host ” 対象パラメータ: $($.Exception.ParamName)” # ArgumentNullException固有プロパティ
}
catch {
Write-Error “予期しないエラー: $($_.Exception.Message)” -ErrorAction Continue
}

Write-Host “n--- Testing Missing Input ---n”

欠落した入力 (UserName)

try {
Process-UserAccount -Role “User” -UserName “” # 空文字列もWhiteSpaceOrNullに含まれる
}
catch [System.ArgumentException] {
Write-Error “パラメータエラー: $($.Exception.Message)” -ErrorAction Continue
Write-Host ” 対象パラメータ: $($.Exception.ParamName)”
}
catch [System.ArgumentNullException] {
Write-Error “パラメータエラー: $($.Exception.Message)” -ErrorAction Continue
Write-Host ” 対象パラメータ: $($.Exception.ParamName)”
}
catch {
Write-Error “予期しないエラー: $($_.Exception.Message)” -ErrorAction Continue
}

“`

この例では、Process-UserAccount関数が受け取るパラメータUserNameとRoleを検証しています。UserNameが空またはホワイトスペースのみであればArgumentNullExceptionを、Roleが定義済みの有効なロールリストに含まれていなければArgumentExceptionをそれぞれthrowしています。これにより、不正な入力値で後続の処理が実行されるのを防ぎ、エラーハンドラー側でパラメータ名や具体的なエラー原因を含む詳細なメッセージを表示できます。

`ValidateScript` との組み合わせ

PowerShellのパラメータ属性の一つである[ValidateScript({...})]は、パラメータバインディングの段階で入力値を検証するための強力なメカニズムです。ValidateScriptブロック内でthrowを使用すると、検証が失敗したときにパラメータバインディングエラー（System.Management.Automation.ParameterBindingException）を生成させることができます。これは、パラメータ検証ロジックをパラメータ定義自体に組み込みたい場合に非常に便利です。

“`powershell
function Set-ItemQuantity {
param(
[Parameter(Mandatory=$true)]
[ValidateScript({
if ($ -lt 0) {
# 負の値は無効。throw を使用して検証エラーを発生させる。
throw “数量($)は負の値であってはなりません。”
}
# 特定の在庫制限など、より複雑なチェックも可能
# if ($ -gt (Get-MaxStockLevel)) { throw “数量($)が在庫制限を超えています。” }
$true # 検証成功時は$trueを返す
})]
[int]$Quantity
)

Write-Host "アイテム数量を $Quantity に設定します。"
# ここで数量に関する処理を記述...

}

有効な数量

Set-ItemQuantity -Quantity 100

Write-Host “n--- Testing Invalid Quantity ---n”

無効な数量 (負の値)

try {
Set-ItemQuantity -Quantity -50
}
catch [System.Management.Automation.ParameterBindingException] {
Write-Error “パラメータ検証エラー: $($.Exception.Message)” -ErrorAction Continue
# 例外メッセージに ValidateScript 内で throw した文字列が含まれる
}
catch {
Write-Error “予期しないエラー: $($.Exception.Message)” -ErrorAction Continue
}
“`

この例では、Quantityパラメータに[ValidateScript]属性を付けています。このスクリプトブロック内で、入力値$_が負の値であればthrowを実行しています。ValidateScript内でthrowされたエラーは、PowerShellのパラメータバインディングシステムによって捕捉され、ParameterBindingExceptionとしてラップされます。呼び出し側では、このParameterBindingExceptionを捕捉することで、パラメータバインディングの段階で発生したエラーを処理できます。この方法は、パラメータの検証ロジックをパラメータ宣言の近くに置くことで、コードの可読性と保守性を向上させます。

2. 予期しない状態の検出

スクリプトの実行中に、予期していなかったが処理を続行できない重大なシステムの状態が検出されることがあります。例えば、必要な設定ファイルが破損している、外部APIからの応答が不正である、必須のサービスが実行されていない、必要なネットワーク共有にアクセスできない、といった状況です。これらの状況は、入力値が不正である場合とは異なり、スクリプトの外部要因や実行環境に依存する問題です。このような場合も、throwを使用してエラーを発生させ、問題を明確に報告し、スクリプトの実行を安全に中断するのが適切です。

“`powershell
function Perform-CriticalOperation {
param(
[string]$SettingsFilePath
)

# 1. 設定ファイルが存在するか確認
if (-not (Test-Path $SettingsFilePath -PathType Leaf)) {
    throw New-Object System.IO.FileNotFoundException "クリティカル操作に必要な設定ファイルが見つかりません。", $SettingsFilePath
}

# 2. 設定ファイルを読み込む（内容の検証も含む）
try {
    $settings = Get-Content $SettingsFilePath | ConvertFrom-Json -ErrorAction Stop
    # 必須の設定値が存在するか検証
    if (-not $settings.ContainsKey('ConnectionString')) {
        throw New-Object System.Configuration.ConfigurationErrorsException "設定ファイル '$SettingsFilePath' に必須の 'ConnectionString' がありません。"
        # System.Configuration.ConfigurationErrorsException は設定関連のエラーに適した例外
    }
    # ConnectionString のフォーマット検証など...
}
catch [System.Text.Json.JsonException] {
    # JSONパースエラーが発生した場合
    throw New-Object System.IO.InvalidDataException "設定ファイル '$SettingsFilePath' のJSON形式が不正です。", $_.Exception
}
catch [System.Configuration.ConfigurationErrorsException] {
    # 上記の必須設定値チェックで throw されたエラーを捕捉し、再スロー
    throw $_.Exception # 元の例外をそのまま再スロー
}
 catch [System.IO.IOException] {
    # その他のファイル読み込みエラー
    throw New-Object System.IO.IOException "設定ファイル '$SettingsFilePath' の読み込み中にIOエラーが発生しました。", $_.Exception
}
catch {
    # その他の予期しないエラー
     throw New-Object System.Exception "設定ファイルの処理中に予期しないエラーが発生しました。", $_.Exception
}


# 3. 外部サービスにアクセスする（サービスが利用可能かチェック）
$requiredService = "MyAppService"
if ((Get-Service -Name $requiredService -ErrorAction SilentlyContinue).Status -ne "Running") {
     throw New-Object System.InvalidOperationException "必須サービス '$requiredService' が実行されていません。クリティカル操作を実行できません。"
}

Write-Host "設定ファイルとサービスが準備できました。クリティカル操作を実行します..."
# クリティカルな操作ロジック...

}

クリティカル操作を呼び出し、エラーを捕捉

try {
Perform-CriticalOperation -SettingsFilePath “C:\App\critical_settings.json”
Write-Host “クリティカル操作が正常に完了しました。”
}
catch [System.IO.FileNotFoundException] {
Write-Error “操作失敗: 設定ファイルが見つかりません。” -ErrorAction Continue
Write-Host ” 詳細: $($.Exception.Message)”
Write-Host ” ファイルパス: $($.Exception.FileName)”
}
catch [System.IO.InvalidDataException] {
Write-Error “操作失敗: 設定ファイルの形式が不正です。” -ErrorAction Continue
Write-Host ” 詳細: $($.Exception.Message)”
if ($.Exception.InnerException) { Write-Host ” 元のエラー: $($.Exception.InnerException.Message)” }
}
catch [System.Configuration.ConfigurationErrorsException] {
Write-Error “操作失敗: 設定ファイルの内容に問題があります。” -ErrorAction Continue
Write-Host ” 詳細: $($.Exception.Message)”
}
catch [System.InvalidOperationException] {
Write-Error “操作失敗: 実行環境に問題があります。” -ErrorAction Continue
Write-Host ” 詳細: $($.Exception.Message)”
}
catch {
Write-Error “クリティカル操作中に予期しない重大なエラーが発生しました。” -ErrorAction Continue
Write-Host ” エラータイプ: $($.Exception.GetType().FullName)”
Write-Host ” メッセージ: $($.Exception.Message)”
Write-Host ” スタックトレース: $($.Exception.StackTrace)”
}
finally {
Write-Host “クリティカル操作の試行が完了しました。”
}
“`

この例では、Perform-CriticalOperation関数が、設定ファイルの存在、内容、および必須サービスの実行状態をチェックしています。これらの前提条件のいずれかが満たされない場合、処理を続行できないと判断し、それぞれに対応する.NET例外クラス（FileNotFoundException、InvalidDataException、ConfigurationErrorsException、InvalidOperationException）をthrowしています。これにより、操作の失敗原因を明確に分類し、呼び出し側でそのタイプに応じた具体的なエラー処理メッセージを表示したり、問題を解決するための指示を提供したりすることが可能になります。特に、catch [System.Text.Json.JsonException]のように、より低レベルで発生したエラーを捕捉し、それを高レベルの例外（ここではSystem.IO.InvalidDataException）としてラップして再スローするパターンは、エラーハンドリングの階層化において有用です。

3. 複雑な処理の早期終了

ネストされた関数呼び出しや深いループ構造の中でエラーが発生した場合、その場でエラー処理を行うのではなく、エラーを発生させて呼び出しスタックを遡り、プログラムのより上位にある適切なエラーハンドラー（通常は最上位のtry-catchブロック）でまとめて処理したい場合があります。throwステートメントは、このような制御フローのジャンプ（unwinding the stack）を行うのに非常に効果的です。これにより、エラーが発生した場所から、エラーを集中管理する場所まで、コードの実行を効率的に移動させることができます。

“`powershell
function Process-SubItem {
param([int]$Value)

Write-Host "    Processing Sub-Item with value: $Value"

if ($Value -lt 0) {
    # 処理不能な状態。FatalErrorException を throw
    # CustomFatalErrorException を定義していると仮定 (System.Exception を継承)
    # throw New-Object CustomFatalErrorException "負の値($Value)は処理できません。", 500
    # または既存の InvalidOperationException を使用
    throw New-Object System.InvalidOperationException "負の値($Value)は処理できません。処理を続行できません。"
}

# 例: 処理時間がかかる作業...
# Start-Sleep -Milliseconds 100
Write-Host "    Sub-Item processing complete."

}

function Process-MainItem {
param([int]$ItemId)

Write-Host "  Processing Main-Item $ItemId"

# 例: 複数のサブアイテムを処理
for ($i = 1; $i -le 3; $i++) {
    Write-Host "    Calling Process-SubItem for item $ItemId, part $i"
    # サブアイテム処理関数を呼び出し
    # $ItemId が 15 の場合、最終的に Process-SubItem に負の値が渡るように計算
    Process-SubItem -Value ($ItemId - 5 * $i)

    Write-Host "    Returned from Process-SubItem for item $ItemId, part $i." # throwされなければ実行される
}

Write-Host "  Main-Item $ItemId processing complete." # throwされなければ実行される

}

function Run-BatchProcess {
param([int]$BatchSize)

Write-Host "Running batch process with size: $BatchSize"

try {
    # 複数のメインアイテムを処理
    for ($item = 1; $item -le $BatchSize; $item++) {
        Write-Host "Calling Process-MainItem for item $item"
        Process-MainItem -ItemId $item # Process-MainItem -> Process-SubItem と呼び出しがネスト
        Write-Host "Returned from Process-MainItem for item $item." # throwされなければ実行される
    }
    Write-Host "Batch process completed successfully."
}
catch {
    # Process-SubItem -> Process-MainItem と呼び出しスタックを遡ってきたエラーを捕捉
    Write-Error "Batch process failed due to an error." -ErrorAction Continue
    Write-Host "  エラータイプ: $($_.Exception.GetType().FullName)"
    Write-Host "  メッセージ: $($_.Exception.Message)"
    Write-Host "  エラー発生箇所 (Invoke-Item): $($_.InvocationInfo.InvocationName)"
    Write-Host "  スタックトレース:"
    Write-Host "$($_.Exception.StackTrace)" # 呼び出し履歴を表示
    # エラーをログに記録するなど
    # throw # さらに上位にエラーを再スローしたい場合
}
finally {
    Write-Host "Batch process finally block executed."
}

Write-Host "Run-BatchProcess function finished." # catchブロックでエラーを処理した場合、ここまで到達する

}

バッチ処理を実行 (BatchSize=2の場合、ItemId=1, 2)

ItemId=1 -> Process-SubItem Value: -4, -9, -14 (エラー発生)

ItemId=2 -> Process-SubItem Value: -3, -8, -13 (エラー発生)

Run-BatchProcess -BatchSize 2

バッチ処理を実行 (BatchSize=3の場合、ItemId=1, 2, 3)

ItemId=3 -> Process-SubItem Value: -2, -7, -12 (エラー発生)

Write-Host “n--- Running Batch Process ---n”
Run-BatchProcess -BatchSize 3
“`

この例では、Run-BatchProcessがProcess-MainItemを呼び出し、Process-MainItemがループ内でProcess-SubItemを複数回呼び出しています。Process-SubItem関数内で、入力値が負の場合にInvalidOperationExceptionがthrowされます。このthrowが実行されると、Process-SubItemの残りのコード、それを呼び出したProcess-MainItemの残りのコード（ループ内の後続の反復やWrite-Host行）は実行されずにスキップされ、呼び出しスタックを遡って最も近いtry-catchブロックであるRun-BatchProcess内のcatchブロックでエラーが捕捉されます。

catchブロックで表示されるスタックトレースを見ると、エラーがProcess-SubItem内で発生し、Process-MainItemを経由してRun-BatchProcessのcatchブロックに到達したことがわかります。この例は、throwがいかにネストされた関数呼び出しから一気に上位のエラーハンドラーまで制御を移すのに効果的であるかを示しています。これにより、エラー処理ロジックをコードの最上位に近い場所に集中させることが可能になり、エラーハンドリングの構造がシンプルになります。

4. カスタム例外の作成と利用 (発展)

標準の.NET例外クラスだけでは表現できない、アプリケーションやスクリプト固有の特定の jenis エラー状態がある場合、カスタム例外クラスを定義して使用することができます。カスタム例外クラスは、エラーの種類をより明確に分類できるだけでなく、エラーに関する追加情報を持たせるカスタムプロパティを追加することも可能です。これは、エラーハンドリングの柔軟性と詳細度を大幅に向上させます。

PowerShellでカスタム例外クラスを作成するには、PowerShell 5.0以降で導入されたクラス定義構文を使用するのが最も簡単です。

“`powershell

PowerShell 5.0 以降で利用可能

System.Exception を継承するカスタム例外クラスを定義

class MyAppSpecificException : System.Exception {
# コンストラクタの定義 (基本クラス System.Exception のコンストラクタを呼び出す)
MyAppSpecificException([string]$message) : base($message) {
# Additional initialization if needed
}

# 追加のプロパティを定義 (例: エラーコード、関連するオブジェクトIDなど)
[int]$ErrorCode

# エラーコード付きのコンストラクタをオーバーロード
MyAppSpecificException([string]$message, [int]$errorCode) : base($message) {
    $this.ErrorCode = $errorCode
}

# InnerException を受け取るコンストラクタも定義しておくと便利
 MyAppSpecificException([string]$message, [Exception]$innerException) : base($message, $innerException) {
 }

# エラーコードと InnerException を受け取るコンストラクタ
 MyAppSpecificException([string]$message, [int]$errorCode, [Exception]$innerException) : base($message, $innerException) {
     $this.ErrorCode = $errorCode
 }

}

カスタム例外を使用する関数

function Perform-DatabaseOperation {
param(
[string]$QueryId,
[string]$DatabaseServer = “DBServer01”
)

Write-Host "Performing operation for QueryId '$QueryId' on server '$DatabaseServer'"

# 例: QueryId の形式が不正な場合
if ($QueryId -notmatch "^\w{3}\d{4}$") {
    # MyAppSpecificException を throw (エラーコード付き)
    throw New-Object MyAppSpecificException "無効なQueryId形式: '$QueryId'。期待される形式は XXXYYYY です。", 1001
}

# 例: データベース接続に失敗した場合 (ここではシミュレーション)
# 実際には Invoke-Sqlcmd や ADO.NET などを使用
$simulatedConnectionSuccess = $false # デモのために接続失敗をシミュレート
if (-not $simulatedConnectionSuccess) {
    # 接続エラーの場合は MyAppSpecificException を throw (別のエラーコード)
    throw New-Object MyAppSpecificException "データベースサーバー '$DatabaseServer' への接続に失敗しました。", 2002
}

# 例: クエリ実行中にエラーが発生した場合 (InnerException 付きで throw)
# try {
#     # Invoke-Sqlcmd -Query "SELECT * FROM NonExistentTable" # SqlException を発生させる
# }
# catch [System.Data.SqlClient.SqlException] {
#     # SQL固有のエラーを捕捉し、カスタム例外としてラップして再スロー
#     throw New-Object MyAppSpecificException "QueryId '$QueryId' の実行中にSQLエラーが発生しました。", 3003, $_.Exception
# }


Write-Host "Database operation for QueryId '$QueryId' completed."

}

カスタム例外を捕捉する

try {
# 無効な QueryId を指定してエラーを発生させる
Perform-DatabaseOperation -QueryId “ABC_123”
# データベース接続失敗をシミュレートする場合 (上記コードで $simulatedConnectionSuccess を $false に)
# Perform-DatabaseOperation -QueryId “XYZ7890”

Write-Host "操作成功"

}
catch [MyAppSpecificException] {
# 定義したカスタム例外タイプを捕捉
Write-Error “アプリケーション固有のエラーを捕捉しました！” -ErrorAction Continue
Write-Host ” エラーメッセージ: $($.Exception.Message)”
Write-Host ” エラーコード: $($.Exception.ErrorCode)” # カスタムプロパティにアクセス可能
if ($.Exception.InnerException) {
Write-Host ” InnerException タイプ: $($.Exception.InnerException.GetType().FullName)”
Write-Host ” InnerException メッセージ: $($.Exception.InnerException.Message)”
}
Write-Host ” 発生箇所: $($.InvocationInfo.ScriptStackTrace)”
}
catch {
# 上記以外のすべての終了型エラーを捕捉
Write-Error “予期しない一般的なエラーが発生しました。” -ErrorAction Continue
Write-Host ” エラータイプ: $($.Exception.GetType().FullName)”
Write-Host ” メッセージ: $($.Exception.Message)”
Write-Host ” 発生箇所: $($_.InvocationInfo.ScriptStackTrace)”
}
finally {
Write-Host “データベース操作処理が完了しました。”
}
“`

この例では、MyAppSpecificExceptionというカスタム例外クラスを定義しています。このクラスはSystem.Exceptionを継承しており、標準のMessageプロパティに加えて、アプリケーション固有のErrorCodeプロパティを持っています。複数のコンストラクタを定義し、メッセージやエラーコード、InnerExceptionなどを設定できるようにしています。

Perform-DatabaseOperation関数では、QueryIdの形式が無効な場合や、データベース接続に失敗した場合に、このカスタム例外をthrowしています。それぞれ異なるエラーコード（1001や2002）を設定しています。また、もし低レベルのSQLエラーが発生した場合には、それを捕捉し、カスタム例外のInnerExceptionとして含めて再スローする例も示しています（コメントアウト部分）。

呼び出し側では、catch [MyAppSpecificException]としてこの特定の例外タイプを捕捉しています。これにより、他の一般的なエラーとは区別して処理でき、カスタムプロパティであるErrorCodeにアクセスして、エラーの種類に応じた詳細な情報を表示したり、異なる回復ロジックを実行したりすることが可能になります。

カスタム例外は、特にモジュール化されたスクリプトや、特定の業務ロジックを含むアプリケーションを開発する際に、エラーの種類を体系的に管理し、エラーハンドリングのコードをより整理された、理解しやすいものにするのに非常に有効です。

`throw` を使用する際の注意点とベストプラクティス

throwは強力なツールですが、その影響範囲が広い（実行フローを中断させる）ため、適切に使用しないとスクリプトのデバッグを困難にしたり、予期しない振る舞いを引き起こしたりする可能性があります。以下にthrowを使用する際の注意点とベストプラクティスを示します。

適切なエラーメッセージを含める:
- throwの引数として渡す文字列やExceptionオブジェクトには、エラーが発生した原因、状況、および可能な解決策を示す、明確で具体的かつユーザーが理解できる情報を含めるべきです。
- 抽象的なメッセージ（例：「エラーが発生しました」「処理に失敗しました」）ではなく、問題の本質を伝えるメッセージ（例：「指定されたファイル ‘C:\report.csv’ が見つかりません」「データベース接続文字列が無効です」）を記述します。これにより、エラーを受け取った人（ユーザーや開発者）が問題を迅速に特定し、対処できるようになります。
- エラーメッセージは、ユーザーインターフェースに表示されたり、ログファイルに記録されたりすることを想定して記述します。
適切なオブジェクトを投げる (System.Exceptionオブジェクトを強く推奨):
- 単なるエラーメッセージを伝えたいだけであっても、可能な限り、文字列ではなくSystem.Exceptionまたはその派生クラスのインスタンスをthrowします。
- これにより、PowerShellのエラー処理システムがExceptionオブジェクトの豊富な情報（型、スタックトレース、 InnerException、カスタムプロパティなど）を活用できるようになり、try-catchブロックでのエラータイプによる分岐や、詳細情報の取得が容易になります。
- 特定のエラー状況に対応する既存の.NET例外クラスがある場合は、それを使用します（例: ファイルがない場合はFileNotFoundException、引数が無効ならArgumentException）。適切なクラスがない場合や、アプリケーション固有の情報を含めたい場合は、カスタム例外クラスの作成を検討します。
- 文字列をthrowするのは、非常にシンプルなスクリプトや、詳細なエラー処理が不要なごく限定的なケースに留めるべきです。
throw と Write-Error の使い分けを明確にする:
- スクリプトまたは現在の処理ブロックの実行を中断する必要がある、回復の見込みが低い致命的なエラーにはthrowを使用します。
- スクリプトの実行を継続できる、あるいは無視しても大きな問題にならない非致命的なエラーや警告にはWrite-Error（既定の非終了型）を使用します。
- Write-Error -ErrorAction Stopは、Write-Errorが生成するErrorRecordの詳細な情報をカスタマイズしつつ、終了型エラーとして扱いたい場合に有効です。特に、コマンドレット内部で標準的なエラーを報告する際に用いられます。どちらを選ぶかは、エラー発生の意図や、ErrorRecordの詳細をどこまで細かく制御したいかによります。独自関数で発生させるアプリケーションレベルの例外としてはthrowがより意図を明確に伝えやすい場合があります。
try-catch-finallyブロックでエラーを捕捉し、適切に処理する:
- throwによって発生する終了型エラーは、try-catch-finallyブロックによって捕捉されることで、その効果を最大限に発揮します。エラーハンドラーがない場合、スクリプトは単にエラーメッセージを表示して終了してしまいます。
- 捕捉したエラーに対してどのような処理を行うかを明確に定義します。これには、ユーザーへの適切なフィードバック、エラーのログ記録（ログファイルへの書き込み、イベントログへの記録など）、リソースのクリーンアップ、代替処理の実行、またはエラーからの回復を試みるロジックなどが含まれます。
- 複数のcatchブロックを使用して、異なる種類のエラーに個別の処理を記述します。最も具体的な例外タイプから先に捕捉するように配置します。
- catchブロック内でエラーを捕捉した場合、通常はエラーは「処理された」と見なされ、スクリプトはcatchブロックの直後から実行を継続します。もしエラーを処理しきれず、さらに上位の呼び出し元にエラーを伝えたい場合は、catchブロックの最後に引数なしのthrowを使用してエラーを再スローします。
finallyブロックで確実に後始末処理を行う:
- スクリプトがファイルやネットワーク接続、データベース接続、COMオブジェクトなど、明示的に解放する必要のあるリソースを使用している場合、エラーが発生したかどうかにかかわらず、これらのリソースが確実に解放されるように、クリーンアップ処理をfinallyブロックに記述します。これにより、エラー発生時のリソースリークを防ぎます。
不要なthrowを避ける:
- throwはコードの実行フローを急に変えるため、多用したり不適切な場所で使用したりすると、スクリプトの論理的な流れを追跡するのが難しくなり、デバッグを困難にすることがあります。
- 単なる情報提供や、スクリプトの実行に致命的な影響を与えない軽微な問題報告のためにthrowを使用すべきではありません。そのような場合は、Write-Warning、Write-Verbose、または非終了型のWrite-Errorを使用します。
エラーの再スロー (throw 単独):
- catchブロック内でエラーを捕捉し、例えばログ記録などの部分的な処理を行った後、そのエラーをさらに上位の呼び出し元に報告したい場合は、引数なしのthrowステートメントを使用します。
- 単にthrowと記述すると、PowerShellは現在処理中のエラーオブジェクト（$_でアクセスできるErrorRecord）を再スローします。これにより、元のエラーのスタックトレースを含むすべての情報が保持されたまま、エラーが上位に伝播されます。
- throw $_.Exceptionのように新しいthrowを記述することも技術的には可能ですが、この場合、新しいスタックトレースが開始されてしまい、元のエラーが発生した正確な位置や呼び出し履歴の情報が失われる可能性があるため、エラーの再スローには引数なしのthrowを推奨します。
グローバルなエラー設定との相互作用 ($ErrorActionPreference):
- throwステートメントによって明示的に発生させられた終了型エラーは、$ErrorActionPreference変数の設定（Continue, SilentlyContinue, Stopなど）に関わらず、常に終了型エラーとして扱われ、既定では実行を中断し、try-catchブロックで捕捉できます。
- ただし、非終了型エラーを$ErrorActionPreference = 'Stop'や-ErrorAction Stopによって終了型エラーとして扱うようにした場合、それらのエラーもtry-catchブロックで捕捉可能になります。この点で、throwとWrite-Error -ErrorAction Stopはtry-catchによる捕捉という点では同様に機能します。

`throw` と他のエラー処理メカニズムの連携

PowerShellのエラー処理システムは複数のメカニズムから構成されており、それぞれが異なる目的や振る舞いを持ちます。throwはこれらのメカニズムと連携して機能します。

try-catch-finallyブロック:
- 前述の通り、throwによって発生する終了型エラーを捕捉する主要なメカニズムです。これは、PowerShellにおける構造化例外処理の基盤となります。現代のスクリプト開発では、try-catch-finallyの使用が強く推奨されています。
trapステートメント:
- try-catch-finallyが導入される以前から存在するエラー処理機構です。スクリプトや関数、または特定のブロック内でエラーが発生した場合に自動的に実行されるコードブロックを定義します。
- throwによって発生する終了型エラーもtrapステートメントで捕捉できます。
- しかし、trapの振る舞い（エラー処理後のスクリプト実行の再開/終了制御）はtry-catchに比べて直感的でなく、スコープの扱いも複雑になりがちです。現在では、新しいコードを書く際にはtry-catch-finallyを使用するのが一般的なベストプラクティスとされています。既存のコードベースでtrapが使用されている場合は、その振る舞いを理解しておく必要がありますが、新規にtrapを使用するよりもtry-catchを使用することを推奨します。
$ErrorActionPreference変数と-ErrorAction共通パラメータ:
- これらは主に非終了型エラーの振る舞いを制御するためのものです。非終了型エラーが発生した際に、それを無視するか、警告として表示するか、ユーザーに確認するか、または終了型エラーに昇格させて実行を停止させるか（Stop）を設定します。
- throwステートメントは、$ErrorActionPreferenceの設定に関わらず、常に終了型エラーを発生させます。これは、throwが開発者の明確な意図による「異常終了」の表明であるためです。
- ただし、$ErrorActionPreference = 'Stop'を設定したり、特定のコマンドレットに対して-ErrorAction Stopを指定したりすることで、通常は非終了型であるエラーを終了型エラーに変換できます。これにより、それらのエラーもtry-catchブロックで捕捉できるようになります。この点において、throwとWrite-Error -ErrorAction Stop（または$ErrorActionPreference='Stop'時のWrite-Errorやコマンドレットエラー）は、try-catchで捕捉可能という共通の性質を持ちます。
$Error変数:
- PowerShellセッション内で発生した最近のエラーのコレクションを保持する自動変数です。
- throwによって発生した終了型エラーがtry-catchブロックで捕捉されずにスクリプトの実行が中断した場合、そのエラー（実際にはErrorRecordオブジェクト）は$Errorコレクションの先頭に追加されます。
- try-catchブロックでエラーが捕捉された場合、そのエラーは既定では$Errorコレクションには追加されません。catchブロック内でエラーを記録したい場合は、明示的にWrite-Error -ErrorAction Continueなどを実行する必要があります。

これらのメカニズムは相互に関連していますが、それぞれが異なるシナリオやエラーの種類に対応しています。throwは、開発者がコード内で能動的に、かつ明確に致命的なエラー状態をシグナルするために使用するツールとして、PowerShellのエラー処理フレームワークの中で重要な役割を果たしています。

まとめ

throwは通常、エラーメッセージを含む文字列または.NETのSystem.Exceptionオブジェクトを引数として使用します。特にSystem.Exceptionオブジェクトやその派生クラスを使用することで、エラーの種類を明確にし、詳細な情報（メッセージ、スタックトレース、例外固有のプロパティなど）をエラーハンドラーに伝えることができます。既存の標準例外クラスが適さない場合は、カスタム例外クラスを定義して利用することも可能です。

throwによって発生した終了型エラーは、PowerShellのtry-catch-finallyブロックによって捕捉され、エラーの種類に応じたカスタマイズされた処理を実行することが可能です。catchブロック内では、特殊変数$_を通じてErrorRecordオブジェクトにアクセスし、エラーの詳細情報を取得できます。finallyブロックは、エラーの有無にかかわらず常に実行され、リソースのクリーンアップに役立ちます。

throwは、入力値の検証エラー、予期しないシステム状態の検出、複雑な処理構造における早期終了など、様々なシナリオで効果的に活用できます。また、Write-Errorとは異なり、既定で実行フローを中断する終了型エラーを生成するため、その使い分けは重要です。処理を続行できない致命的な問題にはthrow、問題を報告しつつ処理を継続させたい非致命的な問題にはWrite-Error（既定）を使用します。

throwを使用する際のベストプラクティスとしては、明確で具体的なエラーメッセージを含めること、可能な限りExceptionオブジェクトを投げること、try-catchブロックでエラーを適切に捕捉し処理すること、そしてfinallyブロックで後始末を行うことなどが挙げられます。引数なしのthrowによるエラーの再スローは、元のエラー情報を保持したままエラーを上位に伝えるための重要なテクニックです。

エラー処理は、単にエラーメッセージを表示するだけでなく、エラー発生時のシステムの安全性を確保し、問題の原因を迅速に特定・解決するための重要な開発手法です。throwステートメントとtry-catch-finallyブロックをマスターし、それらをPowerShellの他のエラー処理メカニズムと組み合わせて適切に活用することは、信頼性が高く、保守しやすいスクリプトを開発するために不可欠なスキルと言えるでしょう。これらのツールを効果的に使い分けることで、PowerShellスクリプトの堅牢性を大幅に向上させることができます。

“`

PowerShellのthrowとは？使い方とエラー処理での活用法

はじめに：PowerShellにおけるエラー処理の重要性

PowerShellのエラーの種類：TerminateとNon-Terminate

throw の基本的な使い方

簡単な例：文字列を投げる

スクリプトの例

上記のthrowが実行されると、以下の行は実行されない

簡単な例：System.Exception オブジェクトを投げる

スクリプトの例

throw で投げられるオブジェクトの種類

例外クラスの利用例

例外が発生する呼び出し

throw と Write-Error の違い

実行フローへの影響

どちらを使うべきか

エラー処理ブロック（try, catch, finally）

エラーオブジェクト ($_) の活用法

存在しないパスを指定してエラーを発生させる

存在する場合の例（エラーは発生しない）

Test-TryCatchThrow -Path $env:TEMP

NullReferenceExceptionを発生させる呼び出し (tryブロック内でコメントアウト解除)

Test-TryCatchThrow -Path $env:TEMP # $null.ToString()が実行されるように変更

throw とエラー処理の応用例

1. 入力値の検証

有効なポート番号

無効なポート番号 (エラー発生)

ValidateScript との組み合わせ

有効なポート番号

無効なポート番号 (検証エラー発生)

2. 予期しない状態の検出

存在しないデータソースを指定

3. 複雑な処理の早期終了

エラーが発生しない呼び出し

エラーが発生する呼び出し (StepCでthrow)

4. カスタム例外の作成と利用 (発展)

PowerShell 5.0 以降で利用可能

カスタム例外を使用する関数

カスタム例外を捕捉する

throw を使用する際の注意点とベストプラクティス

throw と他のエラー処理メカニズムの連携

まとめ

PowerShellのthrowとは？使い方とエラー処理での活用法

はじめに：PowerShellにおけるエラー処理の重要性

PowerShellのエラーの種類：TerminateとNon-Terminate

throw の基本的な使い方

簡単な例：文字列を投げる

スクリプトの例

上記のthrowが実行された場合、以下の行は実行されない

簡単な例：System.Exception オブジェクトを投げる

スクリプトの例

throw で投げられるオブジェクトの種類

例外クラスの利用例

Get-ConfigurationValue 関数を呼び出し、try-catchでエラーを捕捉

throw と Write-Error の違い

実行フローへの影響

ErrorRecordオブジェクト

どちらを使うべきか

エラー処理ブロック（try, catch, finally）

$_ 変数（ErrorRecord）の詳細

存在しないファイルを指定してエラーを発生させる

内容が不正なファイルを指定してエラーを発生させる（一時ファイルを作成）

読み込みエラーをシミュレート（tryブロック内でコメントアウト解除してテスト）

Write-Host “n--- Testing IO Error ---n”

Process-ImportantFile -FilePath “C:\valid_but_access_denied.txt” # このファイルは実際には存在しなくても良い、シミュレーションなので

成功する例（一時ファイルを作成）

throw とエラー処理の応用例

1. 入力値の検証

有効な入力

無効な入力 (Role)

欠落した入力 (UserName)

ValidateScript との組み合わせ

有効な数量

無効な数量 (負の値)

2. 予期しない状態の検出

クリティカル操作を呼び出し、エラーを捕捉

3. 複雑な処理の早期終了

バッチ処理を実行 (BatchSize=2の場合、ItemId=1, 2)

ItemId=1 -> Process-SubItem Value: -4, -9, -14 (エラー発生)

ItemId=2 -> Process-SubItem Value: -3, -8, -13 (エラー発生)

Run-BatchProcess -BatchSize 2

`throw` の基本的な使い方

簡単な例：`System.Exception` オブジェクトを投げる

`throw` で投げられるオブジェクトの種類

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

エラー処理ブロック（`try`, `catch`, `finally`）

エラーオブジェクト (`$_`) の活用法

`throw` とエラー処理の応用例

`ValidateScript` との組み合わせ

`throw` を使用する際の注意点とベストプラクティス

`throw` と他のエラー処理メカニズムの連携

`throw` の基本的な使い方

簡単な例：`System.Exception` オブジェクトを投げる

`throw` で投げられるオブジェクトの種類

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

エラー処理ブロック（`try`, `catch`, `finally`）

`$_` 変数（ErrorRecord）の詳細

Write-Host “`n--- Testing IO Error ---`n”

`throw` とエラー処理の応用例

`ValidateScript` との組み合わせ

`throw` を使用する際の注意点とベストプラクティス

`throw` と他のエラー処理メカニズムの連携

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