2010-11-29 11 views
0

私はメソッドでこのNumberFormatExceptionをキャッチする必要がありますか?

のようなメソッドを持っていると仮定
void A(long input) { 

    ...... 

} 

基本的には、入力が長かったり成功したりすると、他の型をlongに変換することができます。

しかし、間違ったデータ入力があると、NumberFormatExceptionが投げられます。したがって、堅牢な方法は

void A(long input){ 

    try{ 
     ... 
    }catch(NumberFormatException e){ 

    } 

} 

にする必要があります。ただし、このプロジェクトはBSアプリケーションであると主張する開発者もいます。入力はWeb UIから渡されます。したがって、入力が有効であることを確認することができます。そして、この例外を処理する必要はありません。

しかし、私はそれが必須だと思う。どう思いますか?ありがとう。

+2

あなたの質問は、言葉としては意味をなさない。 'input'は長いです。このNumberFormatExceptionはどこから来たはずですか? –

+0

別のメソッドからの入力の場合。そして、入力は文字列 "36000L"です。 – Joseph

+0

あなたは単に、そのシグネチャを引数として文字列を持つ関数を呼び出すことはできません。例外は、呼び出し(あなたの例では、私が想定している何らかの種類のWebフレームワーク)が何を投げても例外ではなく、ここで例外を捕捉することはできません。 –

答えて

0

実際に関数内で例外をキャッチするかどうかは選択肢です。関数の仕様が役立ちます。

しかし、関数が何も返さないため、呼び出し元は何か問題が発生したことを知ることを意図していますか?それが問題でなければ、捕まえても大丈夫かもしれません。それが問題であれば、例外を伝播することは、関数の署名が変更されていない限り、エラーの存在を通知する良い方法です。

0

私はtry-catchブロックを持っていても、それを必要としていないよりも使用しない方が良いと思います。入力がWeb-UIに渡されるという事実は、将来どの検証ロジックも変更できることを意味します。

ただし、ユーザーにエラーが通知されていることを確認する必要があります。

+0

例外を処理する明確な方法がないと、例外がスローされるようにする方がよいと思います。 – cHao

+0

はい、私はそう思います。 – Joseph

+0

私はこのメソッドが自己完結型であると仮定していました。 – npinti

2

メソッドがlongを受け入れる場合、メソッド自体に変換はありません。メソッドが呼び出される前に引数がスタックにプッシュされるときに変換され、変換をキャッチできませんメソッド自体のエラーです。

引数を持つStringを渡す場合は、独自の変換を行います。例外をキャッチするかスローする必要があります。いずれの方法も同じように有効で、無効な値をどのように処理するかによって選択が異なります。 「これは本当に数字ではない」という例外をスローするのであれば、例外をスローすることもできます。

0

時には、コードで例外的な条件が発生しないことを99.5%が確信しています。しかし、残りの0.5%は、アプリケーションやデータベースの整合性を害することができれば、例外をキャッチし、悪い事が起こる前に、実行時例外をスローした方がよいかもしれません:

private void String(String validatedStringWithALongValue) { 
    try { 
    long l = Long.parseLong(validatedStringWithALongValue); 
    // ... do what has to be done 
    } catch (NumberFormatException oops) { 
    Exception e = new RuntimeException(oops); 
    log.error("Bad news - validation failed or has been bypassed", e); 
    throw e; 
    } 
} 
0

この質問への答えは、あなたのシステム設計に依存します。

  • それはデータ型の検証を実行するには、Web UIの責任である場合は、次のレベルには検証が行われていることを前提とし、NumberFormatExceptionが伝播することを可能にするために、それが合理的です。しかし、ある時点では、サーバー側のコードは予期しない例外を捕捉してログに記録し、適切なHTTP応答コードを生成する必要があります。

  • データ型の検証を実行するのがWeb UIの責任でない場合は、次のレベルで適切な(ユーザーフレンドリーな)エラーメッセージを生成し、ユーザーがそれを簡単に修正する必要があります。 (例えば、HTMLで実装されたWeb UIはどの程度にデータを検証することができません。)

検証各種の責任が属するどこのシステム設計が明確に指定されていない場合は、デザインに欠陥があります。

数字を文字列として渡すことをお勧めします。これは必要かもしれません。例えばレイヤーが別々のWebアプリケーションコンテナにある場合しかし、検証とビジネスロジックが同じサーブレット内にある場合、前者はまたはlongを渡し、後者には数字のStringを渡さないでください。

最後に、概念上内部的なWeb APIのいずれかが実際に公開されている場合、ハッキングから保護するための検証を少なくとも行う必要があります。たとえば、ユーザー向けのWeb UIがHTML + Javascriptの場合、通信する公開HTTPベースのAPIが必要です。ハッカーがあなたのGUIを迂回し、HTTP APIにディレクトリを話すのは簡単なことです。したがって、HTTP APIは、悪用しようと試みるのに必要な範囲で少なくとも要求を検証する必要があります。

関連する問題