Do you know how this code works?

Yesterday, once again faced with the interesting behavior of the code, I decided to give a couple of examples from C # and MS SQL, which at one time surprised me.

Example 1. Swap the values ​​of variables (C #)

I met this behavior a few years ago when I first started learning C #. Using the familiar method to change the values ​​of 2 variables in places, I was surprised to find that it does not work.

// 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 .

As a result, the first time everything goes fine and the values ​​of the variables change, and the second time, contrary to expectations, our variable x is reset to zero.

Example 2. We translate a number into a string (MS SQL)

Here is an example of how the cast and convert functions can add surprises.

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

* This source code was highlighted with Source Code Highlighter .

Although this behavior is documented in MSDN, I ran into this before I read about it.

Example 3. Using NOT IN and IN in a condition (MS SQL)

This example is also described in MSDN, but I learned about such behavior only when a program error occurred because of it.

--
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 .

Unlike IN, which just skips null, NOT IN always returns an empty selection. In general, after a little reflection, on the topic “why so?”, The result no longer seems unusual.
')

Example 4. Finally and unhandled exception (C #)

The following situation seems unusual to me, because it changes behavior depending on whether you catch an exception or not.
So, we will write a class with one method, which will have a try-catch-finally block. The method call will also be wrapped in 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 .

Everything will work as it should:
1.Try
2.F Catch
3.Finally
4.Main catch

Now remove the try-catch block from the Main method and run the program again. This time the result will be slightly different, although in both cases the exception leaves the F () method:
1.Try
2.F Catch
3. Error information
4.Finally

Conclusion

In most cases, unusual at first glance behavior turns out to be quite extensible or already documented. But, you see, there are few who thoroughly read help before writing code. So I wish you less often to meet with such surprises.