【C#】文字列を入力するとエラーの表示が出るようにしたい

Question

######文字列を入力するとエラーの表示が出るようにしたいのですが、どのようにすれば良いでしょうか。

負の数が入力されるまで、キーボードから繰り返し数値を入力するプログラムを作成中です。
以下が現在のコードです。負の数が入力されると終了するようになっています。空白はエラー表示が出るようになっています。

その他、修正推奨箇所がございましたら、よろしければ教えてください。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            var num = 0;
            while(num >= 0)
            {
                Console.Write("負数を入力してください：");
                var line = Console.ReadLine();
                if (line == "")
                {
                    Console.WriteLine("入力結果：エラー");
                    continue;
                }
                num = int.Parse(line);
                Console.WriteLine($"入力結果；{num}");
            }
            Console.WriteLine("負数が入力されました");
        }
    }
}

Comments

[退会済みユーザー]

〇〇〇と入力したら、△△△となることを期待して、コードを書いたが、結果は□□□となってしまう・・・というように書きましょう。

[m.ts10806]

intParseに失敗したら、で良いのでは？

[funabashi]

ご回答ありがとうございます。
そのように書く必要がある理由を具体的に教えてください。

まずはintParseに失敗したらで試してみます。

[退会済みユーザー]

ちなみに数値への変換成功・失敗も同時に確認できるTryParseというメソッドもあります

[m.ts10806]

何が問題なのか明示されてないための指摘ですね。
自身で要件に対して取り組まれたことがなく「どうしたら」は質問ではなく作業依頼です。

[退会済みユーザー]

> そのように書く必要がある理由を具体的に教えてください。

あなたの質問はコードを丸投げして赤の他人にデバッグしてくれといってるのと同じだと認識できませんか？ 認識できない、もしくは認識してるがそれの何が悪いと思っているなら、話は通じない人なので、ほっときます。

[funabashi]

具体的な回答ではなかったので単純に疑問がございました。質問への回答は義務ではないはずですから、そこであえて抽象的な修正依頼をする理由もわからなかったので。いずれにしても喧嘩しにきたわけではないので、不快にさせてしまったら申し訳ございませんでした。
コード丸投げで質問するのは良くないというご意見だったということですね。大変貴重なご意見ありがとうございました。今後はご回答をいただけるように質問内容には気を付けます。

TryParseメソッド教えてくださりありがとうございます。そちら参考にさせていただいてコード書き直してみます。

[YT0014]

teratailにてご質問をされるのでしたら、以下をご確認ください。
https://teratail.com/help/question-tips#questionTips1

[YT0014]

負数としか表示していませんが、負の整数限定は、正しい仕様ですか？
また、コードレビュー希望なら、詳細な仕様の提示は必須です。
仕様不明では、このように成否が判断できません。

[Zuishin]

int.Parse に失敗したら数値ではないというのは非常に具体的では？
どこが抽象的なのかわからないんですが。

喧嘩とか不快とかなぜそのような言葉が出てくるのかも意味が分かりません。

[funabashi]

int.Parseに失敗したらは非常にわかりやすいご回答でした。誤解を招いてしまい大変申し訳ございません。
すみません、後ほど修正させていただきます。皆様ありがとうございました。今後は気をつけます。

Answer 1

出来るだけ元のコードを変えずに回答いたします。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            var num = 0;
            while (num >= 0)
            {
                var line = 0;
                try
                {
                    Console.Write("負数を入力してください：");
                    line = int.Parse(Console.ReadLine());
                }
                catch
                {
                    Console.WriteLine("入力結果：エラー");
                    continue;
                }

                num = line;
                Console.WriteLine($"入力結果；{num}");
            }
            Console.WriteLine("負数が入力されました");
        }
    }
}

try-catchというものがあるので、これを使えばエラー判定が簡単にできます。
tryの中でエラーが起きたら、catchの中に入る、そんな処理です。

line = int.Parse(Console.ReadLine());で「数字のみ入れることが出来るよ！」みたいな処理にします。

数字以外、要するに空白や、文字列が入ってきたときにcatchに入ることでエラーを出します。

こんな感じでいかがでしょうか。

Comments

[退会済みユーザー]

ユーザー入力の検証を例外を発生させて行うのは止めるべきです。詳しく検証するなら正規表現、今回の例では TryParse が適切だと思います。

[pepperleaf]

例外は重たい(遅い)ですね。想定できる範囲は使うものでは無いでするね。

[fana]

「失敗した理由が(ある程度?)知りたい　→　Parse 側を使う」とたら，その選択はどの程度不適切でしょうか？

[Zuishin]

昔はこういうコードは普通でしたね。公式サイトにも多くのサンプルがあります。

https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/types/how-to-convert-a-string-to-a-number
https://docs.microsoft.com/ja-jp/dotnet/standard/base-types/parsing-numeric

C 言語ではエラーハンドリングがネストの山になっていたので、それを解消することは例外という機構が作られた最大の目的だと思います。
つまりこのように例外的な入力をはじいて主なるロジックをシンプルにするために例外を使うというのは、例外の本来の使い方であったと認識しています。
言うなれば例外機構は Maybe モナドのような使い方をされていたわけですね。
重いというのはありますが、ユーザーの入力に限って言うなら入力の方が重いので無視できます。

しかし時代が進んでこのような方法を使わなくてもよくなったので、TryParse やタプルとパターンマッチングを使ったモダンな方法が今は推奨されます。

[退会済みユーザー]

.NET アプリの例外処置について、自分的に一般的と思うことを書きます。

(1) 予測可能で正しい業務フローに戻すことができる「業務エラー」（例：ユーザーの入力間違い）と、予測できないもしくは予測はできても何の対応もできない「例外」（例：DB サーバーダウン）を区別して対処。

(2) 「例外」はランタイムに拾わせてアプリケーションを停止させる。無かったことにして、ユーザが作業を続けられるようにすると、大事なデータを壊したりと、強制的に停止させるより好ましからざる状況に陥るかも。

(3) よほどのことがない限り try-catch は書かない。

(4) キャッチせざるを得ない場合でも Execption はキャッチしない。キャッチせざるを得ないとしても範囲を絞る。例えば DB 関係の例外が予測されるなら SqlException に限定して catch し、Number プロパティなどでエラーの内容を調べて対処するとか。

(5) 間違って補足してしまった例外は throw する。（注：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

自分が持っている Microsoft の本に、上に書いた原則に則ったサンプルが載っていたので紹介しておきます。

データベースに INSERT する際に PK 制約違反で発生する例外のみ catch して「業務エラー」（2 重登録）としてユーザーに再入力を促し、その他は再 throw してランタイムに拾わせてアプリケーションを停止させるというものです。

public bool InsertAuthors()
{
var connection = new SqlConnection("接続文字列");
var command = new SqlCommand("INSERT INTO authors VALUES ('172-32-1176', 'White', ...)", connection);
try
{
connection.Open();
try
{
command.ExecuteNonQuery();
}
catch(SqlException sqle)
{
if (sqle.Number == 2627)
{
return false;
}
else
{
throw;
}
}
}
finally
{
connection.Close();
}

return true;
}

以下の記事も参考になると思います。

例外の推奨事項
https://docs.microsoft.com/ja-jp/dotnet/standard/exceptions/best-practices-for-exceptions