SolidWorks APIの深淵：Rebuild/Selectionエラーを「握りつぶさない」ための堅牢な例外設計
SolidWorks APIを扱うエンジニアにとって、`swModel.ForceRebuild3` や `swFeature.Select2` は諸刃の剣だ。多くの初学者はエラーを恐れて `On Error Resume Next` で全てを包み隠すが、それはシステムの死を意味する。
真の自動化エンジニアは、エラーを「予期せぬ事故」ではなく「制御すべきイベント」として定義する。本稿では、SolidWorksのドキュメントライフサイクルを支配し、エラーの発生源を特定してシステムを安全に帰還させるための「極限の例外ハンドリング」を伝授する。
—
1. なぜ「Rebuild Error」は握りつぶしてはならないのか
SolidWorksのフィーチャ生成は「履歴の連鎖」だ。特定のフィーチャで破綻した際、その後の処理を強行すれば、メモリ上のオブジェクト参照は腐敗し、SolidWorks自体がクラッシュ（あるいはゾンビプロセス化）する。
我々が求めるのは、「どのフィーチャが、なぜ失敗したか」というメタデータだ。これを実現するには、`Err.Number` の監視だけでなく、`IModelDocExtension::GetLastRebuildError` を駆使した能動的な検知が必要になる。
—
2. 実践的例外ハンドリング・テンプレート
以下は、フィーチャ操作時に発生するエラーを検知し、ログを吐き出して安全に中断するアーキテクチャの骨子だ。
Option Explicit
‘ 伝説のアーキテクトが推奨するエラーハンドリング・パターン
Public Sub RobustFeatureOperation(swModel As SldWorks.ModelDoc2, featureName As String)
Dim swFeat As SldWorks.Feature
Dim errCode As Long
On Error GoTo ErrorHandler
‘ 1. オブジェクトの存在確認（メモリリーク防止の基本）
Set swFeat = swModel.FeatureManager.FeatureByName(featureName)
If swFeat Is Nothing Then Err.Raise vbObjectError + 1001, , “Feature Not Found: ” & featureName
‘ 2. Selection Mark Errorの回避: 正確な選択
If Not swFeat.Select2(False, 0) Then
Err.Raise vbObjectError + 1002, , “Selection Failed: ” & featureName
End If
‘ 3. Rebuild監視の核心
swModel.ForceRebuild3 False
‘ エラー確認APIを呼び出し、詳細を特定する
errCode = swModel.Extension.GetLastRebuildError
If errCode <> 0 Then
HandleRebuildError errCode, featureName
End If
Exit Sub
ErrorHandler:
‘ システムログへの書き出し（Windows API経由のファイルI/Oを推奨）
LogSystemError Err.Number, Err.Description, featureName
‘ オブジェクト解放の強制
Set swFeat = Nothing
Resume Next ‘ 必要に応じてリトライロジックへ遷移
End Sub
Private Sub HandleRebuildError(errCode As Long, fName As String)
‘ SolidWorks APIのリビルドエラーコードに基づき分類
Select Case errCode
Case swRebuildError_e.swRebuildError_FeatureFailed
Debug.Print “Critical: ” & fName & ” is broken.”
‘ 他のケースを網羅的に記述
End Select
End Sub
—
3. シニアエンジニアが意識すべき「メモリの死角」
オブジェクトの明示的解放（Dispose）
VBAはガベージコレクションが脆弱だ。`Set swFeat = Nothing` を怠れば、複雑なマクロを実行するたびにSolidWorksのプロセスが肥大化し、数時間後にはメモリ不足で落ちる。特にループ内でフィーチャ生成を行う場合、各イテレーションの最後で確実に参照を破棄せよ。
Windows APIによるログ出力
`Open #1` でテキストを書き出すのはレガシーな手法だ。大規模なシステム連携を行うなら、`kernel32.dll` の `WriteFile` を使用し、バッファリングを制御したログ出力を実装すべきだ。これにより、SolidWorksのクラッシュ時にもログが消失することなく、最後の瞬間のフィーチャ名を記録できる。
—
4. 堅牢性を高めるための「境界線」設計
1. Selection Markの厳密化: `Select2` メソッドの引数 `Append` や `Mark` を適当に設定してはならない。特にマルチボディやコンフィギュレーションが絡む場合、明示的に `swModel.ClearSelection2 True` を実行し、クリーンな状態で操作を開始する。
2. パフォーマンスの最適化: `swApp.Visible = False` を活用し、UI描画を抑制する。これが最強の高速化であり、同時に「人間が操作してエラーを出す」というヒューマンエラーの余地を排除する最善手だ。
3. システム間連携のプロトコル: 他システム（PDMやERP）と連携する際は、エラー発生時に「エラーコード＋フィーチャ名＋タイムスタンプ」を含むJSON/XMLを生成し、上位システムに通知する「死活監視」を組み込め。
—
最後に：コードは「対話」である
SolidWorks APIは、単なる命令の羅列ではない。ソフトウェアの内部構造という「巨大な生命体」との対話だ。エラーハンドリングを怠ることは、その対話を放棄することに他ならない。
君たちが書く一行のコードが、設計者の思考を形にする。その責任の重さを自覚し、エラーを恐れるのではなく、エラーを「システムをより強固にするためのフィードバック」として掌握してほしい。
健闘を祈る。
