>>942
もし省略可能(optional)な入力フィールド上で特定の条件(たとえばチェックボックスがオンの時)だけ
編集を許可したいという、ありふれたケースであれば：
・(1) を isEditable として (2) を isActive という論理型の属性にするか、
　あるいは Active(活性中)/Inactive(非活性) という列挙型にする
・またはより一般的(総称的)に (2) を isEnable という論理型の属性、または
　Enable(有効)/Disable(無効) という列挙型でもいい

または特定のユーザが持つ権限に応じて編集可能性が決定するケースであれば：
・(1) を isEditable として (2) をアクセス制御を表す isAccessable という論理型の属性、または
　Allow(許可)/Deny(禁止) という列挙型にする
・またはより一般的(総称的)に (2) を isPermitted という論理型の属性、または
　Permit(許可)/Prohibit(禁止) という列挙型でもいい(>>943)

これらのユーザの対応によって回復可能なエラーを例外で実装すること(>>944)が正当されるケースは、
まず有り得ないと思う
GUIアプリのコード設計で例外を投げて対処するのが明らかに正当化されるケースは、
処理を続行できない致命的なエラーを検出したケースくらいだろう


これらはGUI部品オブジェクトのインスタンス状態が実行中に(=動的に)変化する場合だけど、
設計時に(=静的に)編集可能性が決定する局面もある
たとえばテキストや画像のラベルは「そもそも」編集不可だし、
テキスト入力フィールドやリストボックスは「そもそも」編集可能という属性値を持つ
これをコードで実装するケースであれば：
・(1) をクラス属性として実装して (2) をインスタンス属性として実装し、命名はどちらも isEditable とする