ฉันเพิ่งทำงานกับDateTimeวัตถุและเขียนสิ่งนี้:

DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?

เอกสาร Intellisense สำหรับAddDays()บอกว่าจะเพิ่มวันในวันที่ซึ่งไม่ได้ - จริง ๆ แล้วมันคืนวันที่มีวันที่เพิ่มเข้าไปดังนั้นคุณต้องเขียนมันเช่น:

DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date

อันนี้กัดฉันหลายครั้งก่อนดังนั้นฉันคิดว่ามันจะมีประโยชน์ในการแคตตาล็อก C # gotchas ที่เลวร้ายที่สุด

private int myVar;
public int MyVar
{
    get { return MyVar; }
}

Blammo แอปของคุณล่มโดยไม่มีการติดตามสแต็ก เกิดขึ้นตลอดเวลา

(ให้สังเกตเมืองหลวงMyVarแทนตัวพิมพ์เล็กmyVarในช่องว่าง)

Type.GetType

Type.GetType(string)หนึ่งซึ่งผมเคยเห็นจำนวนมากกัดของคนเป็น พวกเขาสงสัยว่าทำไมมันทำงานประเภทในการชุมนุมของตัวเองและบางชนิดชอบแต่ไม่ได้System.String System.Windows.Forms.Formคำตอบก็คือว่ามันเพียง mscorlibแต่ดูในปัจจุบันการประกอบและใน

วิธีการที่ไม่ระบุชื่อ

C # 2.0 แนะนำวิธีการที่ไม่ระบุชื่อนำไปสู่สถานการณ์ที่น่ารังเกียจเช่นนี้:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            ThreadStart ts = delegate { Console.WriteLine(i); };
            new Thread(ts).Start();
        }
    }
}

สิ่งที่จะพิมพ์ออกมา? มันขึ้นอยู่กับการตั้งเวลา มันจะพิมพ์ตัวเลข 10 แต่มันอาจจะไม่พิมพ์ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ซึ่งเป็นสิ่งที่คุณคาดหวัง ปัญหาคือมันเป็นiตัวแปรที่ถูกดักจับไม่ใช่ค่า ณ จุดที่สร้างผู้รับมอบสิทธิ์ สิ่งนี้สามารถแก้ไขได้อย่างง่ายดายด้วยตัวแปรพิเศษในขอบเขตที่เหมาะสม:

using System;
using System.Threading;

class Test
{
    static void Main()
    {
        for (int i=0; i < 10; i++)
        {
            int copy = i;
            ThreadStart ts = delegate { Console.WriteLine(copy); };
            new Thread(ts).Start();
        }
    }
}

การดำเนินการบล็อกตัววนซ้ำที่เลื่อนออกไป

"การทดสอบหน่วยของชายยากจน" นี้ไม่ผ่าน - ทำไมไม่

using System;
using System.Collections.Generic;
using System.Diagnostics;

class Test
{
    static IEnumerable<char> CapitalLetters(string input)
    {
        if (input == null)
        {
            throw new ArgumentNullException(input);
        }
        foreach (char c in input)
        {
            yield return char.ToUpper(c);
        }
    }

    static void Main()
    {
        // Test that null input is handled correctly
        try
        {
            CapitalLetters(null);
            Console.WriteLine("An exception should have been thrown!");
        }
        catch (ArgumentNullException)
        {
            // Expected
        }
    }
}

คำตอบคือรหัสภายในซอร์สโค้ดของCapitalLettersโค้ดไม่ได้ถูกดำเนินการจนกว่าMoveNext()จะเรียกเมธอดiterator เป็นครั้งแรก

ฉันมีความแปลกประหลาดอื่น ๆ บางบนของหน้า brainteasers

โยนข้อยกเว้นอีกครั้ง

gotcha ที่ได้รับนักพัฒนาใหม่ ๆ จำนวนมากคือซีแมนทิกส์ re-Throw exception

มีเวลามากมายที่ฉันเห็นโค้ดดังนี้

catch(Exception e) 
{
   // Do stuff 
   throw e; 
}

ปัญหาคือมันล้างการติดตามสแต็กและทำให้การวินิจฉัยปัญหายากขึ้นมากทำให้คุณไม่สามารถติดตามตำแหน่งที่เกิดข้อยกเว้นได้

รหัสที่ถูกต้องเป็นทั้งคำสั่ง throw โดยไม่มี args:

catch(Exception)
{
    throw;
}

หรือล้อมรอบข้อยกเว้นในอีกอันหนึ่งและใช้การยกเว้นภายในเพื่อรับการติดตามสแต็กดั้งเดิม:

catch(Exception e) 
{
   // Do stuff 
   throw new MySpecialException(e); 
}

หน้าต่างนาฬิกาของไฮเซนเบิร์ก

สิ่งนี้สามารถกัดคุณอย่างรุนแรงหากคุณทำสิ่งที่ต้องการโหลดเช่นนี้:

private MyClass _myObj;
public MyClass MyObj {
  get {
    if (_myObj == null)
      _myObj = CreateMyObj(); // some other code to create my object
    return _myObj;
  }
}

สมมติว่าคุณมีรหัสอื่นที่ใช้สิ่งนี้:

// blah
// blah
MyObj.DoStuff(); // Line 3
// blah

ตอนนี้คุณต้องการที่จะแก้ปัญหาCreateMyObj()วิธีการของคุณ ดังนั้นคุณจึงใส่เบรกพอยต์ในบรรทัดที่ 3 ด้านบนด้วยความตั้งใจที่จะก้าวเข้าไปในรหัส สำหรับการวัดที่ดีคุณสามารถใส่เบรกพอยต์บนบรรทัดด้านบนที่ระบุ_myObj = CreateMyObj();และแม้แต่เบรกพอยต์ภายในCreateMyObj()ตัวเอง

รหัสจะถึงจุดพักของคุณในบรรทัดที่ 3 คุณก้าวเข้าสู่โค้ด คุณคาดว่าจะป้อนรหัสตามเงื่อนไขเพราะ_myObjเห็นได้ชัดว่าเป็นโมฆะใช่ไหม? เอ่อ ... ดังนั้น ... ทำไมมันข้ามเงื่อนไขและตรงไปที่return _myObj! คุณวางเมาส์ไว้เหนือ _myObj ... และแน่นอนว่ามันมีค่า! มันเกิดขึ้นได้อย่างไร!

คำตอบก็คือ IDE ของคุณทำให้เกิดค่าเนื่องจากคุณมีหน้าต่าง "เฝ้าดู" เปิดอยู่ - โดยเฉพาะหน้าต่างเฝ้าดู "รถยนต์" ซึ่งแสดงค่าของตัวแปร / คุณสมบัติทั้งหมดที่เกี่ยวข้องกับบรรทัดการทำงานปัจจุบันหรือก่อนหน้า เมื่อคุณกดเบรกพอยต์ของคุณบนบรรทัดที่ 3 หน้าต่างนาฬิกาตัดสินใจว่าคุณจะสนใจที่จะรู้ถึงคุณค่าของMyObj- ดังนั้นเบื้องหลังการเพิกเฉยจุดพักของคุณมันไปและคำนวณค่าของMyObjคุณ - รวมถึงการโทรไปCreateMyObj()ที่ กำหนดค่าของ _myObj!

นั่นเป็นเหตุผลที่ฉันเรียกสิ่งนี้ว่าหน้าต่าง Heisenberg Watch - คุณไม่สามารถสังเกตเห็นคุณค่าโดยไม่ส่งผลกระทบต่อมัน ... :)

Gotcha!

แก้ไข - ฉันรู้สึกว่าความคิดเห็นของ @ ChristianHayter สมควรได้รับการรวมไว้ในคำตอบหลักเนื่องจากดูเหมือนว่าวิธีแก้ไขปัญหาที่มีประสิทธิภาพสำหรับปัญหานี้ ดังนั้นเมื่อใดก็ตามที่คุณมีทรัพย์สินที่ขี้เกียจ ...

ตกแต่งคุณสมบัติของคุณด้วย [DebuggerBrowsable (DebuggerBrowsableState.Never)] หรือ [DebuggerDisplay ("<โหลดตามต้องการ>")] - คริสเตียนเฮเตอร์

นี่คืออีกครั้งที่ทำให้ฉัน:

static void PrintHowLong(DateTime a, DateTime b)
{
    TimeSpan span = a - b;
    Console.WriteLine(span.Seconds);        // WRONG!
    Console.WriteLine(span.TotalSeconds);   // RIGHT!
}

TimeSpan.Secondsเป็นส่วนวินาทีของช่วงเวลา (2 นาทีและ 0 วินาทีมีค่าวินาทีเป็น 0)

TimeSpan.TotalSecondsเป็นช่วงเวลาทั้งหมดที่วัดเป็นวินาที (2 นาทีมีค่าวินาทีทั้งหมด 120)

หน่วยความจำรั่วเนื่องจากคุณไม่ได้ยกเลิกการเชื่อมต่อเหตุการณ์

สิ่งนี้ยิ่งทำให้นักพัฒนาอาวุโสบางคนที่ฉันรู้จักทราบ

ลองนึกภาพรูปแบบ WPF ที่มีหลายสิ่งในนั้นและที่ใดที่หนึ่งที่นั่นคุณสมัครรับกิจกรรม หากคุณไม่ได้ยกเลิกการเป็นสมาชิกแบบฟอร์มทั้งหมดจะถูกเก็บไว้ในหน่วยความจำหลังจากที่ถูกปิดและยกเลิกการอ้างอิง

ฉันเชื่อว่าปัญหาที่ฉันเห็นคือการสร้าง DispatchTimer ในรูปแบบ WPF และสมัครสมาชิกเหตุการณ์ Tick ถ้าคุณไม่ทำ - = ในตัวจับเวลาที่ฟอร์มของคุณรั่วหน่วยความจำ!

ในตัวอย่างนี้โค้ดการฉีกขาดของคุณควรมี

timer.Tick -= TimerTickEventHandler;

อันนี้เป็นเรื่องยากโดยเฉพาะอย่างยิ่งเมื่อคุณสร้างอินสแตนซ์ของ DispatchTimer ภายในรูปแบบ WPF ดังนั้นคุณจะคิดว่ามันจะเป็นการอ้างอิงภายในที่จัดการโดยกระบวนการรวบรวมขยะ ... น่าเสียดายที่ DispatchTimer ใช้รายการภายในแบบคงที่ของการสมัครสมาชิกและบริการ คำร้องขอบนเธรด UI ดังนั้นการอ้างอิงคือ 'เป็นเจ้าของ' โดยคลาสสแตติก

อาจไม่ใช่ gotcha จริง ๆ เพราะพฤติกรรมนั้นเขียนไว้อย่างชัดเจนใน MSDN แต่คอของฉันเสียหนึ่งครั้งเพราะฉันพบว่าค่อนข้างตอบโต้:

Image image = System.Drawing.Image.FromFile("nice.pic");

ผู้ชายคนนี้ออกจาก"nice.pic"ไฟล์ที่ถูกล็อคจนกว่าภาพจะถูกกำจัด ในเวลาที่ฉันเผชิญหน้ากับมันฉันก็คงจะดีใจที่ได้โหลดไอคอนได้ทันทีและไม่รู้ตัว (ตอนแรก) ว่าฉันจบลงด้วยการเปิดและล็อคไฟล์มากมาย! รูปภาพติดตามตำแหน่งที่โหลดไฟล์จาก ...

วิธีแก้ปัญหานี้ ฉันคิดว่าสายการบินเดียวจะทำงานได้ ฉันคาดว่าจะมีพารามิเตอร์เพิ่มเติมสำหรับFromFile()แต่ไม่มีเลยฉันจึงเขียนสิ่งนี้ ...

using (Stream fs = new FileStream("nice.pic", FileMode.Open, FileAccess.Read))
{
    image = System.Drawing.Image.FromStream(fs);
}

หากคุณนับ ASP.NET ฉันจะบอกว่าวงจรชีวิตของเว็บฟอร์มนั้นเป็น gotcha ที่ยอดเยี่ยมสำหรับฉัน ฉันใช้เวลานับไม่ถ้วนในการดีบักโค้ดเว็บฟอร์มที่เขียนไม่ดีเพียงเพราะนักพัฒนาจำนวนมากไม่เข้าใจว่าจะใช้ตัวจัดการเหตุการณ์เมื่อใด (รวมอยู่ด้วยเศร้า)

โอเวอร์โหลด == ตัวดำเนินการและคอนเทนเนอร์ที่ไม่ได้พิมพ์ (รายการอาร์เรย์, ชุดข้อมูล ฯลฯ ):

string my = "my ";
Debug.Assert(my+"string" == "my string"); //true

var a = new ArrayList();
a.Add(my+"string");
a.Add("my string");

// uses ==(object) instead of ==(string)
Debug.Assert(a[1] == "my string"); // true, due to interning magic
Debug.Assert(a[0] == "my string"); // false

การแก้ปัญหา?

• ใช้เสมอstring.Equals(a, b)เมื่อคุณเปรียบเทียบชนิดสตริง

• การใช้ข้อมูลทั่วไปต้องการList<string>ให้แน่ใจว่าตัวถูกดำเนินการทั้งสองเป็นสตริง

[Serializable]
class Hello
{
    readonly object accountsLock = new object();
}

//Do stuff to deserialize Hello with BinaryFormatter
//and now... accountsLock == null ;)

คุณธรรมของเรื่องราว: ผู้เริ่มต้นฟิลด์จะไม่ทำงานเมื่อยกเลิกการปรับวัตถุ

DateTime.ToString ("dd / MM / yyyy") ; สิ่งนี้จะไม่ให้ dd / MM / yyyy เสมอไป แต่จะคำนึงถึงการตั้งค่าภูมิภาคและแทนที่ตัวคั่นวันที่ของคุณขึ้นอยู่กับว่าคุณอยู่ที่ไหน ดังนั้นคุณอาจได้ dd-MM-yyyy หรืออะไรทำนองนั้น

วิธีที่เหมาะสมในการทำเช่นนี้คือใช้DateTime.ToString ("dd '/' MM '/' yyyy");

DateTime.ToString ("r")ควรจะแปลงเป็น RFC1123 ซึ่งใช้ GMT GMT อยู่ภายในเสี้ยววินาทีจาก UTC และตัวระบุรูปแบบ "r" จะไม่แปลงเป็น UTCแม้ว่า DateTime ที่เป็นปัญหาจะถูกระบุเป็น Local

ซึ่งจะส่งผลให้ gotcha ต่อไปนี้ (แตกต่างกันไปขึ้นอยู่กับเวลาท้องถิ่นของคุณจาก UTC)

DateTime.Parse("Tue, 06 Sep 2011 16:35:12 GMT").ToString("r")
>              "Tue, 06 Sep 2011 17:35:12 GMT"

อ๊ะ!

ฉันเห็นสิ่งนี้โพสต์เมื่อวันก่อนและฉันคิดว่ามันค่อนข้างคลุมเครือและเจ็บปวดสำหรับผู้ที่ไม่รู้

int x = 0;
x = x++;
return x;

ตามที่จะส่งคืน 0 และไม่ใช่ 1 อย่างที่คาดไว้

ฉันมาช้าไปงานปาร์ตี้นี้ แต่ฉันมี gotchas สองตัวที่กัดฉันทั้งคู่เมื่อเร็ว ๆ นี้:

การแก้ไขวันที่และเวลา

คุณสมบัติเห็บนั้นใช้เวลา 10 ล้านวินาทีต่อวินาที (100 นาโนวินาทีบล็อก) แต่ความละเอียดไม่ใช่ 100 นาโนวินาทีมันประมาณ 15 มิลลิวินาที

รหัสนี้:

long now = DateTime.Now.Ticks;
for (int i = 0; i < 10; i++)
{
    System.Threading.Thread.Sleep(1);
    Console.WriteLine(DateTime.Now.Ticks - now);
}

จะให้ผลลัพธ์ของ (ตัวอย่าง):

0
0
0
0
0
0
0
156254
156254
156254

ในทำนองเดียวกันถ้าคุณดูที่ DateTime.Now.Millisecond คุณจะได้รับค่าเป็นชิ้นส่วนโค้งมนที่ 15.625ms: 15, 31, 46 เป็นต้น

ลักษณะการทำงานนี้แตกต่างจากระบบสู่ระบบแต่มี gotchas ที่เกี่ยวข้องกับการแก้ปัญหาอื่น ๆใน API วันที่ / เวลานี้

Path.Combine

วิธีที่ยอดเยี่ยมในการรวมพา ธ ไฟล์ แต่ก็ไม่ได้ทำงานตามที่คุณคาดหวังเสมอไป

หากพารามิเตอร์ที่สองเริ่มต้นด้วย\ตัวอักษรมันจะไม่ให้เส้นทางที่สมบูรณ์:

รหัสนี้:

string prefix1 = "C:\\MyFolder\\MySubFolder";
string prefix2 = "C:\\MyFolder\\MySubFolder\\";
string suffix1 = "log\\";
string suffix2 = "\\log\\";

Console.WriteLine(Path.Combine(prefix1, suffix1));
Console.WriteLine(Path.Combine(prefix1, suffix2));
Console.WriteLine(Path.Combine(prefix2, suffix1));
Console.WriteLine(Path.Combine(prefix2, suffix2));

ให้ผลลัพธ์นี้กับคุณ:

C:\MyFolder\MySubFolder\log\
\log\
C:\MyFolder\MySubFolder\log\
\log\

เมื่อคุณเริ่มต้นกระบวนการ (ใช้ System.Diagnostics) ที่เขียนไปยังคอนโซล แต่คุณไม่เคยอ่านสตรีม Console.Out หลังจากเอาท์พุตจำนวนหนึ่งแอปของคุณจะปรากฏขึ้นเพื่อหยุดการทำงาน

ไม่มีทางลัดของโอเปอเรเตอร์ใน Linq-To-Sql

ดูที่นี่ที่นี่

ในระยะสั้นภายในส่วนเงื่อนไขของแบบสอบถาม Linq-To-Sql คุณไม่สามารถใช้ทางลัดตามเงื่อนไขเช่น||และ&&เพื่อหลีกเลี่ยงข้อยกเว้นการอ้างอิงที่เป็นโมฆะ Linq-To-Sql จะประเมินทั้งสองด้านของตัวดำเนินการ OR หรือ AND แม้ว่าเงื่อนไขแรกจะตัดความจำเป็นในการประเมินเงื่อนไขที่สอง!

การใช้พารามิเตอร์เริ่มต้นด้วยวิธีการเสมือน

abstract class Base
{
    public virtual void foo(string s = "base") { Console.WriteLine("base " + s); }
}

class Derived : Base
{
    public override void foo(string s = "derived") { Console.WriteLine("derived " + s); }
}

...

Base b = new Derived();
b.foo();

เอาต์พุต:
ฐานที่ได้รับ

วัตถุค่าในคอลเลกชันที่ไม่แน่นอน

struct Point { ... }
List<Point> mypoints = ...;

mypoints[i].x = 10;

ไม่มีผล

mypoints[i]ส่งคืนสำเนาของPointวัตถุที่มีค่า C # อย่างมีความสุขช่วยให้คุณปรับเปลี่ยนเขตข้อมูลของการคัดลอก ไม่ทำอะไรเลยในใจ

อัปเดต: สิ่งนี้ดูเหมือนจะได้รับการแก้ไขใน C # 3.0:

Cannot modify the return value of 'System.Collections.Generic.List<Foo>.this[int]' because it is not a variable

อาจไม่ใช่สิ่งที่แย่ที่สุด แต่บางส่วนของกรอบงาน. net ใช้องศาขณะที่คนอื่นใช้เรเดียน (และเอกสารที่ปรากฏใน Intellisense ไม่เคยบอกคุณว่าคุณต้องไปที่ MSDN เพื่อค้นหา)

ทั้งหมดนี้สามารถหลีกเลี่ยงได้โดยมีAngleชั้นเรียนแทน ...

สำหรับโปรแกรมเมอร์ C / C ++ การเปลี่ยนไปใช้ C # นั้นเป็นเรื่องธรรมดา อย่างไรก็ตาม gotcha ที่ใหญ่ที่สุดที่ฉันเคยพบเป็นการส่วนตัว (และได้เห็นกับผู้อื่นที่ทำให้การเปลี่ยนแปลงเดียวกัน) ไม่เข้าใจความแตกต่างระหว่างคลาสและ structs ใน C # อย่างเต็มที่

ใน C ++ คลาสและ structs เหมือนกัน พวกเขาแตกต่างกันในการมองเห็นเริ่มต้นเท่านั้นที่คลาสเริ่มต้นการมองเห็นส่วนตัวและ structs เริ่มต้นการมองเห็นสาธารณะ ใน C ++ นิยามคลาสนี้

    class A
    {
    public:
        int i;
    };

เทียบเท่ากับนิยามของ struct นี้

    struct A
    {
        int i;
    };

อย่างไรก็ตามใน C # คลาสเป็นประเภทการอ้างอิงในขณะที่ structs เป็นประเภทค่า นี้จะทำให้บิ๊กความแตกต่างใน (1) การตัดสินใจเมื่อจะใช้หนึ่งในช่วงอื่น ๆ (2) การทดสอบความเสมอภาควัตถุ (3) ผลการดำเนินงาน (เช่นมวย / unboxing) ฯลฯ

มีข้อมูลทุกชนิดในเว็บที่เกี่ยวข้องกับความแตกต่างระหว่างสองสิ่ง (เช่นที่นี่ ) ฉันขอแนะนำให้ทุกคนที่ทำการเปลี่ยนมาใช้ภาษา C # เป็นอย่างน้อยมีความรู้ในการทำงานเกี่ยวกับความแตกต่างและความหมายของพวกเขา

การรวบรวมและกำจัดขยะ () แม้ว่าคุณจะไม่ต้องทำอะไรเพื่อเพิ่มหน่วยความจำแต่คุณยังต้องเพิ่มทรัพยากรผ่าน Dispose () นี่เป็นสิ่งที่ง่ายอย่างมากที่จะลืมเมื่อคุณใช้ WinForms หรือติดตามวัตถุในทางใดทางหนึ่ง

ใช้อาร์เรย์ IList

แต่อย่านำไปใช้ เมื่อคุณโทรเพิ่มมันจะบอกคุณว่ามันไม่ทำงาน เหตุใดคลาสจึงใช้อินเทอร์เฟซเมื่อมันไม่สามารถรองรับได้

คอมไพล์ แต่ใช้งานไม่ได้:

IList<int> myList = new int[] { 1, 2, 4 };
myList.Add(5);

เรามีปัญหานี้มากเพราะ serializer (WCF) เปลี่ยน ILists ทั้งหมดเป็นอาร์เรย์และเราได้รับข้อผิดพลาดรันไทม์

foreach ลูปขอบเขตตัวแปร!

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    l.Add(() => s);
}

foreach (var a in l)
    Console.WriteLine(a());

พิมพ์ห้า "amet" ในขณะที่ตัวอย่างต่อไปนี้ทำงานได้ดี

var l = new List<Func<string>>();
var strings = new[] { "Lorem" , "ipsum", "dolor", "sit", "amet" };
foreach (var s in strings)
{
    var t = s;
    l.Add(() => t);
}

foreach (var a in l)
    Console.WriteLine(a());

MS SQL Server ไม่สามารถจัดการกับวันที่ก่อนปี 1753 อย่างมีนัยสำคัญที่ไม่ได้ซิงค์กับDateTime.MinDateค่าคงที่. NET ซึ่งคือ 1/1/1 ดังนั้นถ้าคุณพยายามที่จะบันทึกใจวันที่ที่ไม่ถูกต้อง (ตามที่เพิ่งเกิดขึ้นกับฉันในการนำเข้าข้อมูล) หรือเพียงแค่วันเกิดของ William the Conqueror คุณจะเดือดร้อน ไม่มีวิธีแก้ไขเฉพาะหน้าสำหรับสิ่งนี้ หากคุณต้องการทำงานกับวันที่ก่อนปี 1753 คุณต้องเขียนวิธีแก้ปัญหาของคุณเอง

Linq Caching Gotcha ที่น่ารังเกียจ

ดูคำถามของฉันที่นำไปสู่การค้นพบนี้และบล็อกเกอร์ที่ค้นพบปัญหา

กล่าวโดยย่อ DataContext เก็บแคชของวัตถุ Linq-to-Sql ทั้งหมดที่คุณเคยโหลด หากบุคคลอื่นทำการเปลี่ยนแปลงใด ๆ กับระเบียนที่คุณโหลดไว้ก่อนหน้านี้คุณจะไม่สามารถรับข้อมูลล่าสุดได้แม้ว่าคุณจะโหลดบันทึกซ้ำอย่างชัดเจน!

นี่เป็นเพราะคุณสมบัติเรียกว่าObjectTrackingEnabledDataContext ซึ่งโดยค่าเริ่มต้นเป็นจริง หากคุณตั้งค่าคุณสมบัตินั้นเป็นเท็จจะมีการโหลดระเบียนใหม่ทุกครั้ง ... แต่ ... คุณไม่สามารถยืนยันการเปลี่ยนแปลงใด ๆ ในระเบียนนั้นด้วย SubmitChanges ()

Gotcha!

สัญญาใน Stream.Readเป็นสิ่งที่ฉันได้เห็นการเดินทางของผู้คนจำนวนมาก:

// Read 8 bytes and turn them into a ulong
byte[] data = new byte[8];
stream.Read(data, 0, 8); // <-- WRONG!
ulong data = BitConverter.ToUInt64(data);

เหตุผลนี้ผิดที่Stream.Readจะอ่านจำนวนไบต์ที่ระบุมากที่สุดแต่มีอิสระที่จะอ่านเพียง 1 ไบต์แม้ว่าจะมีอีก 7 ไบต์ก่อนสิ้นกระแสก็ตาม

มันไม่ได้ช่วยที่มีลักษณะนี้เพื่อให้คล้ายกับStream.Writeที่มีการรับประกันว่าจะได้เขียนทุก bytes ถ้ามันกลับมาพร้อมกับไม่มีข้อยกเว้น นอกจากนี้ยังไม่ได้ช่วยให้รหัสข้างต้นทำงานเกือบตลอดเวลาทำงานเกือบตลอดเวลาและแน่นอนว่ามันไม่ได้ช่วยให้ไม่มีวิธีที่สะดวกและสะดวกในการอ่านอย่างถูกต้อง N ไบต์

ดังนั้นในการเสียบรูและเพิ่มการรับรู้นี่คือตัวอย่างของวิธีที่ถูกต้องในการทำสิ่งนี้:

    /// <summary>
    /// Attempts to fill the buffer with the specified number of bytes from the
    /// stream. If there are fewer bytes left in the stream than requested then
    /// all available bytes will be read into the buffer.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="buffer">Buffer to write the bytes to.</param>
    /// <param name="offset">Offset at which to write the first byte read from
    ///                      the stream.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    /// <returns>Number of bytes read from the stream into buffer. This may be
    ///          less than requested, but only if the stream ended before the
    ///          required number of bytes were read.</returns>
    public static int FillBuffer(this Stream stream,
                                 byte[] buffer, int offset, int length)
    {
        int totalRead = 0;
        while (length > 0)
        {
            var read = stream.Read(buffer, offset, length);
            if (read == 0)
                return totalRead;
            offset += read;
            length -= read;
            totalRead += read;
        }
        return totalRead;
    }

    /// <summary>
    /// Attempts to read the specified number of bytes from the stream. If
    /// there are fewer bytes left before the end of the stream, a shorter
    /// (possibly empty) array is returned.
    /// </summary>
    /// <param name="stream">Stream to read from.</param>
    /// <param name="length">Number of bytes to read from the stream.</param>
    public static byte[] Read(this Stream stream, int length)
    {
        byte[] buf = new byte[length];
        int read = stream.FillBuffer(buf, 0, length);
        if (read < length)
            Array.Resize(ref buf, read);
        return buf;
    }

เหตุการณ์ที่เกิดขึ้น

ฉันไม่เคยเข้าใจว่าเหตุใดเหตุการณ์จึงเป็นคุณลักษณะภาษา มีความซับซ้อนในการใช้: คุณต้องตรวจสอบโมฆะก่อนโทรคุณต้องยกเลิกการลงทะเบียน (ตัวคุณเอง) คุณไม่สามารถหาผู้ที่ลงทะเบียนได้ (เช่น: ฉันลงทะเบียนแล้วหรือยัง) เหตุใดเหตุการณ์จึงไม่เป็นเพียงแค่คลาสในห้องสมุด โดยทั่วไปเป็นผู้เชี่ยวชาญList<delegate>หรือไม่?

วันนี้ฉันแก้ไขข้อผิดพลาดที่คลี่คลายไปเป็นเวลานาน ข้อผิดพลาดอยู่ในคลาสทั่วไปที่ใช้ในสถานการณ์แบบมัลติเธรดและฟิลด์ int แบบคงที่ถูกใช้เพื่อให้การซิงโครไนซ์ล็อคฟรีโดยใช้ Interlocked ข้อผิดพลาดเกิดขึ้นเนื่องจากการสร้างอินสแตนซ์ของคลาสทั่วไปสำหรับแต่ละประเภทมีสแตติกของตนเอง ดังนั้นแต่ละเธรดมีฟิลด์สแตติกของตนเองและไม่ได้ใช้ล็อกตามที่ต้องการ

class SomeGeneric<T>
{
    public static int i = 0;
}

class Test
{
    public static void main(string[] args)
    {
        SomeGeneric<int>.i = 5;
        SomeGeneric<string>.i = 10;
        Console.WriteLine(SomeGeneric<int>.i);
        Console.WriteLine(SomeGeneric<string>.i);
        Console.WriteLine(SomeGeneric<int>.i);
    }
}

สิ่งนี้พิมพ์ 5 10 5

สามารถนับจำนวนได้มากกว่าหนึ่งครั้ง

มันจะกัดคุณเมื่อคุณนับจำนวนขี้เกียจและคุณวนซ้ำสองครั้งและได้ผลลัพธ์ที่แตกต่างกัน (หรือคุณได้ผลลัพธ์เดียวกัน แต่ดำเนินการสองครั้งโดยไม่จำเป็น)

ตัวอย่างเช่นในขณะที่เขียนการทดสอบบางอย่างฉันต้องการไฟล์ชั่วคราวบางอย่างเพื่อทดสอบตรรกะ:

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName());

foreach (var file in files)
    File.WriteAllText(file, "HELLO WORLD!");

/* ... many lines of codes later ... */

foreach (var file in files)
    File.Delete(file);

ลองนึกภาพความประหลาดใจของฉันเมื่อFile.Delete(file)พ่นFileNotFound!!

สิ่งที่เกิดขึ้นที่นี่คือการfilesนับซ้ำได้ซ้ำสองครั้ง (ผลลัพธ์จากการทำซ้ำครั้งแรกจะไม่ถูกจดจำ) และในการทำซ้ำใหม่แต่ละครั้งที่คุณจะโทรซ้ำPath.GetTempFilename()ดังนั้นคุณจะได้รับชื่อไฟล์ชั่วคราว

แน่นอนว่าโซลูชันนี้มีความกระตือรือร้นที่จะระบุค่าโดยใช้ToArray()หรือToList():

var files = Enumerable.Range(0, 5)
    .Select(i => Path.GetTempFileName())
    .ToArray();

สิ่งนี้ยิ่งน่ากลัวเมื่อคุณทำอะไรแบบมัลติเธรดเช่น:

foreach (var file in files)
    content = content + File.ReadAllText(file);

และคุณรู้ว่าcontent.Lengthยังคงเป็น 0 หลังจากเขียนทั้งหมด !! จากนั้นคุณก็เริ่มตรวจสอบอย่างจริงจังว่าคุณไม่มีสภาพการแข่งขันเมื่อ ... หลังจากหนึ่งชั่วโมงที่สูญเปล่าไปแล้ว ... คุณก็รู้ว่ามันเป็นเพียงแค่สิ่งเล็ก ๆ น้อย ๆ ที่คุณลืมไปได้เลย!

เพิ่งพบหนึ่งแปลกที่ฉันติดอยู่ในการแก้ปัญหาในขณะที่:

คุณสามารถเพิ่มค่า null สำหรับ int ที่สามารถเป็นโมฆะได้โดยไม่ต้องทำการเว้นระยะห่าง

int? i = null;
i++; // I would have expected an exception but runs fine and stays as null

TextInfo textInfo = Thread.CurrentThread.CurrentCulture.TextInfo;

textInfo.ToTitleCase("hello world!"); //Returns "Hello World!"
textInfo.ToTitleCase("hElLo WoRld!"); //Returns "Hello World!"
textInfo.ToTitleCase("Hello World!"); //Returns "Hello World!"
textInfo.ToTitleCase("HELLO WORLD!"); //Returns "HELLO WORLD!"

ใช่พฤติกรรมนี้ได้รับการบันทึกไว้ แต่ไม่สามารถทำให้ถูกต้องได้