VisualStudioではtrycatch内での例外でも一時停止されるため作業するときに困っています。
何が困るのか、何がしたいのか質問文からは分かりませんでしたが、そもそも try - catch の使い方を十分に理解してなくて、やらなくてもいい(たぶん、やるべきではない)ことを考えているような気がします。(もし、違ったら失礼しました)
予測できないもしくは予測はできても何の対応もできない「例外」(例えば DB サーバーダウン)が発生した場合は、ユーザーがそのまま作業を続けて事態を悪化させないためにも、例外をランタイムに拾わせてアプリケーションを停止させるべきです。
また、質問のコードは catch (Exception ex) と Exception をキャッチして例外を握りつぶしていますが、それも感心しません。
予測可能で正常な業務フローに戻せる業務エラー(例えばユーザーの入力ミスなど)を処理するという目的ならほかにもっとマシな手段がありそうです。
例外発生でアプリを停止する際にユーザーへの通知が必要なら集約的例外処置という手段を取るべきです。
上記の詳しい話は以下の記事に書いてありますので一読されることをお勧めします。
.NETの例外処理 Part.1
https://blogs.msdn.microsoft.com/nakama/2008/12/29/net-part-1/
.NETの例外処理 Part.2
https://blogs.msdn.microsoft.com/nakama/2009/01/02/net-part-2/
記事の内容を簡単にまとめると:
(1) 予測可能で正しい業務フローに戻すことができる「業務エラー」(例:ユーザーの入力間違い)と、予測できないもしくは予測はできても何の対応もできない「例外」(例:DB サーバーダウン)を区別して対処。
(2) 「例外」はランタイムに拾わせてアプリケーションを停止させる。
(3) よほどのことがない限り try-catch は書かない。
(4) キャッチせざるを得ない場合でも Execption はキャッチしない。(範囲を絞る。例えば DB 関係の例外で予測される SqlException に限定して catch するとか)
(5) 間違って補足してしまった例外は throw する。例えば SqlException に含まれる PK 制約違反だけは「業務エラー」として処置したいが、その他が原因で発生した SqlException を catch してしまった場合。(注:catch ブロックでキャッチした例外を throw するとスタックトレースが途切れるので単に throw と書く)
(6) ユーザーへの通知が必要なら集約的例外処置を利用する。
あと、.NET 4 からは破損状態例外は catch できなくなっているそうですが、「それでも Catch (Exception e) を使用するのはよくない」ということについては以下の記事を見てください。
破損状態例外を処理する
https://docs.microsoft.com/ja-jp/archive/msdn-magazine/2009/february/clr-inside-out-handling-corrupted-state-exceptions