私は嫌いなメソッドの一つです。使う局面にならないように設計しますし。使う必要を感じません。
とは言うものの、プロジェクトによったら容認していたり、コーディング標準に使用を明記していたり、コーダー任せだったりします。
Application.Exit()の挙動は癖があり、メッセージポンプから空になってから終了すると記載されています。が呼び出し側の継続する命令は実行されます。
以下のようなソースを持って誰かが相談に来ました。「強制終了してもデータがCommitされてしまう」と。
Public Class DLL
Public Sub 処理()
'いろいろ
If 不具合条件あり Then Application.Exit()
'いろいろ
End Sub
End Class
Public Class Form1
Private Sub Apli_Exit_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Apli_Exit.Click
da.BeginTransaction()
'処理いろいろ
If 判定 Then dll.処理()
da.commint()
'処理いろいろ
End Sub
End Class
因みに Class DLLは別ソースで単独DLLになってます。
一番の問題はApplication.Exit()がその時点で終了すると思っていること。
次に、ステップ実行すれば、 Application.Exit()後に da.commit()が実行するのが確認できるのに怠っていること。
なにより問題なのは、DLL内で Application.Exit()を発行してること。
こういう強力な命令があると作法など何処吹く風になってしまいます。 CでもLong Jumpがあってスタックやメモリ状態の復帰作業を省略するために使っている人を見かけたことがあります。いずれもアプリシナリオが醜くなるので、嫌です。
しかし、このあたりの美意識(っていうのかな?)のないプロジェクトは点在しています。基準策定者はマニュアルの文言だけで判断せずに、思い込みでなく、動作検証をしてから取り入れて欲しいものです。
その割には、細かなネーミング規則にこだわったりしているので、策定者やレビュアーは重要度の判断力とセンスが必要でしょう。
「End ステートメント よりマシだし、言語仕様として存在するので、使ってもいいはずだ」.....この類の論理は盗人にも3分の理の感じがします。
特にBasicは過去の互換性という宿命から、好ましくないメソッドが残っていたりします。CLRでもFrameWork.1.xの旧メソッドが温存されてます。
学習者に "好ましくないメソッドを知れ"と言うのは酷なのだろうか。