4

VB6 アプリで、さまざまな場所で実行時エラーが発生しています。

これはエラー処理が不十分な結果であることはわかっていますが、コードを分析して実行時エラーの影響を受けやすい場所を確認することはできますか?

4

6 に答える 6

3

どのアプリケーションも、外部リソースへの呼び出しに関するエラー処理が行われない実行時エラーの影響を受けやすいため、これらのポイントを開始点として特定できます。

私は、エラー処理をVB6コードにレトロフィットできる無料のツール（何年も前）を使用しました。これは、少なくともエラーとそれらが発生したポイントを記録します。

ここにあります: VB6 で簡単にエラーを処理するための HuntErr アドイン

于 2010-05-09T06:50:49.887 に答える
2

コード ベース内のすべてのメソッド (関数、サブルーチン、プロパティなど) にエラー処理ステートメントがあることを確認する必要があります。すべてのエラーが実行時エラーを生成できるわけではないことはおそらく事実ですが、事前に多くの分析を行わなくても、アプリケーションがクラッシュするのを防ぐことができます。

実行可能なコード行の前に、「On Error GoTo...」というラベルが付いたステートメントがあることを確認し、メソッドの最後にエラー処理コードを含むそのラベルを付けてください。このテキストの挿入を自動化できるMZ-Tools 3.0という無料のツールを使用しました。オプションに [エラー ハンドラー] タブがあり、挿入するテキストとその場所を指定できます。これは私のように見えるものです：

    On Error GoTo l{PROCEDURE_NAME}_Error

    {PROCEDURE_BODY}

    Exit {PROCEDURE_TYPE}

l{PROCEDURE_NAME}_Error:

    LogError "{MODULE_NAME}", "{PROCEDURE_NAME}", Err, Err.Description

次に、LogError 関数が存在することを確認し、確認できるログ ファイルにエラーを書き込みます。

于 2010-05-14T16:34:41.450 に答える
1

VB6 アプリの実行時エラーの一般的な原因には、次のものがあります。

  • 存在しないコレクション内のキーへのアクセス
  • 何もないオブジェクトのメソッドまたはプロパティを呼び出す
  • 文字列が null の場合、CLng を使用して文字列を数値に変換する
  • その長さを超えて配列にアクセスする (Split を呼び出した後、文字列に期待した数の部分があると想定した後など)

したがって、他の人が提案したことを実行し、実際のエラーがどこから発生しているかを分析することに加えて、コード内でこれらのような領域を探し、それらの周りに適切なエラー処理を配置することから始めることができます. 多くの場合、最善の「エラー処理」には On Error を使用することはまったく含まれていませんが、次のような境界ケースをチェックすることでエラーを事前に防止することに注意してください。

  • イフ ノット オブジェクト イズ ナッシング
  • Len(文字列) > 0 の場合
  • If UBound(array) > x

等...

于 2010-05-13T14:10:29.180 に答える
0

ここには、On Error GoTo推奨事項と、bwarnerが言及している亀裂を通り抜ける一般的なエラーの両方に関するいくつかの良い答えがあります。

しかし、範囲を広げて組み込みツールを利用して、ブレークポイント、式の監視などのコードを分析し、特に実行時エラーのデバッグに適したもの、ローカル ウィンドウ (デバッグでは見過ごされがちですが、非常に強力です)、およびコール スタックを使用します。ここから多くの優れた情報を得ることができます:コードのデバッグとエラーの処理

それについて考えるべき他のことが役立つかもしれません：

  1. CodeSMART 2009 for VB6やVB Project Analyzerなどの分析に役立つツールに投資してください。
  2. 既存のアプリケーションを VB.NET に移植してみてください。実際に移植して使用するのではなく、修正が必要な点について変換ログを表示します。
于 2010-05-15T06:38:04.883 に答える
0

VB6 では、イベント関数がエラー処理なしで呼び出されると、まさにランタイム エラーが発生します。したがって、少なくともすべてのイベント処理関数 (Form.Open() など) は、エラー ハンドラーで囲まれている必要があります (はい、VB6 にはエラー ハンドラーがないことはわかっています)。このような）：

これをすべてのイベント処理関数の最初の行として使用します (これは、最後に On Error を設定する大きな有効なラベルです)。

¦¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯: On Error GoTo ErrorHandler:

これらすべての関数の最後でこれを使用します。

¦____________________________________________________________________________________________________________________________________: Exit Sub
ErrorHandler: handleError CodeDb, "Form_frm_filter_deletecolum", "cmd_deletecolum_Click", err.Number, err.description, err.Source, err.LastDllError, err.Helpfile, err.HelpContext, Erl: err.Clear

ただし、2 つの文字列をモジュール名と関数名に置き換えます。On Error Goto 0そして、それぞれを に置き換えますOn Error Goto ErrorHandler。

ここで、指定された引数で関数 handleError を作成し (私のアプリでは、バグ追跡システムにバグ レポートを自動的に送信します)、適切なエラー メッセージを表示します。

エラーが発生した行を記憶し、完全な情報を蓄積するために、同様の行を他のすべての行 (非イベント関数、または他の関数によって呼び出されたばかりの関数) に追加する事前構築済みのプロセスを用意することで、これをさらに推し進めました。スタック トレース (ええ、VB6 のスタック トレース!)。さらに、このプロセスでは、各行に行番号が追加されるため、エラー ハンドラの Erl 部分で指定されます。

私たちのツールはいくつかの MS Access モジュールとして書かれているので、単純に提供することはできませんが、どこに行けばよいかがわかります。

于 2010-05-18T21:05:31.593 に答える
0

Ryan の回答と応答のコメントに従って、すべてのルーチンにエラー処理を配置する必要はありません。すべてのイベントと(および API コールバックがない場合は API コールバック) だけです。Sub Main()

API コールバックは、Win32API によって直接呼び出されるルーチンを参照し、ほとんどの場合は をDeclared使用して関数に渡されますAddressOf。(つまり、コードを検索してAddressOf、引数として言及されているすべてのルーチンに、エラーをキャッチし、エラーが発生しないようにするエラー ハンドラーがあることを確認します。)

そして、これが元の質問に実際には答えていないことに気付きました (ただし、Ryan の回答に対するコメントを考えると、最初のステップとしては適切です): すべてのイベントなどでエラー処理を行うと、すべてのエラーをキャッチできます。 、しかし、すべてのエラーがどこで発生したかを直接分析することはできません。各エラーの正確な原因をより正確に特定するには、少なくともエラーをログに記録するイベントによって呼び出されるすべてのルーチンにエラー ログを拡張する必要があります。

于 2010-05-18T11:58:57.850 に答える