このコードの仕組みを知っていますか?

昨日、再び興味深いコードの動作に直面したため、C#とMS SQLからいくつかの例を挙げることにしました。



例1.変数の値を交換します(C#)



数年前、C#を学び始めたばかりのときにこの振る舞いに出会いました。 おなじみの方法を使用して、2つの変数の値を場所ごとに入れ替えると、機能しないことがわかって驚きました。

// 2

int x = 1, y = 2;



// xor

x ^= y;

y ^= x;

x ^= y;



// [x=2;y=1]

Console .WriteLine( "x = {0};y = {1}" , x, y);



// ,

x ^= y ^= x ^= y;



// [x=0;y=2]

Console .WriteLine( "x = {0};y = {1}" , x, y);




* This source code was highlighted with Source Code Highlighter .






その結果、最初にすべてが正常に実行されて変数の値が変更され、2回目は予想に反して変数xをリセットします。



例2.数値を文字列に変換する(MS SQL)



キャストと変換が驚きをもたらす方法の例を次に示します。

cast (1000 as varchar (3)) -- '*'

cast (1000 as nvarchar(3)) -- Error




* This source code was highlighted with Source Code Highlighter .






この動作はMSDNで文書化されていますが、この記事を読む前にこれに遭遇しました。



例3.条件でのNOT INおよびINの使用(MS SQL)



この例はMSDNでも説明されていますが、この動作が原因でプログラムでエラーが発生した場合にのみ、この動作がわかりました。

--

create table #tmpTable

(

id int

)



/* 1 10*/



-- select '

select * from #tmpTable where id in (1,2, null ,3) --: 3

select * from #tmpTable where id not in (1,2, null ,3)--: 0



--

drop table #tmpTable




* This source code was highlighted with Source Code Highlighter .






単にヌルをスキップするINとは異なり、NOT INは常に空の選択を返します。 一般に、「なぜこれがそうなのか」というトピックについて少し考えた後、結果はもはや異常ではないように思われます。



例4.最後に、未処理の例外(C#)



次の状況は、例外をキャッチするかどうかによって動作が変わるため、私には珍しいようです。

そのため、try-catch-finallyブロックが存在する1つのメソッドでクラスを作成します。 また、メソッド呼び出しをtry-catchでラップします。

class C

{

public void F()

{

try

{

Console .WriteLine( "Try" );

throw new Exception( "some exception" );

}

catch (Exception ex)

{

Console .WriteLine( "F Catch" );

throw ex;

}

finally

{

Console .WriteLine( "Finally" );

}

}

}



static void Main( string [] args)

{

try

{

C c = new C();

cF();

}

catch (Exception)

{

Console .WriteLine( "Main catch" );

}

}




* This source code was highlighted with Source Code Highlighter .






すべてが正常に機能します。

1.試してみる

2.Fキャッチ

3.最後に

4.メインキャッチ



次に、Mainメソッドからtry-catchブロックを削除して、プログラムを再度実行します。 今回は結果が少し異なりますが、どちらの場合も例外はF()メソッドを離れます:

1.試してみる

2.Fキャッチ

3.エラー情報

4.最後に



おわりに



ほとんどの場合、一見異常な動作は非常にわかりやすいか、すでに文書化されています。 しかし、コードを書く前に徹底的にヘルプを読む人はほとんどいないことを認めなければなりません。 ですから、このような驚きに出会わないことを願っています。



All Articles