“ ถือว่าคำเตือนทั้งหมดเป็นข้อผิดพลาดยกเว้น…” ใน Visual Studio


124

ใน Visual Studio ฉันสามารถเลือกตัวเลือก "ปฏิบัติต่อคำเตือนเป็นข้อผิดพลาด" เพื่อป้องกันไม่ให้โค้ดของฉันรวบรวมหากมีคำเตือนใด ๆ ทีมของเราใช้ตัวเลือกนี้ แต่มีคำเตือนสองประการที่เราอยากจะเก็บไว้เป็นคำเตือน

มีตัวเลือกในการระงับคำเตือน แต่เราต้องการให้แสดงเป็นคำเตือนเพื่อไม่ให้เกิดผล

ดูเหมือนว่าวิธีเดียวที่จะได้รับพฤติกรรมที่เราต้องการคือป้อนรายการหมายเลขคำเตือน C # ทั้งหมดลงในกล่องข้อความ "คำเตือนเฉพาะ" ยกเว้นสองรายการที่เราต้องการให้ถือว่าเป็นคำเตือน

นอกเหนือจากอาการปวดหัวในการบำรุงรักษาข้อเสียที่ใหญ่ที่สุดของแนวทางนี้คือคำเตือนบางอย่างไม่มีตัวเลขดังนั้นจึงไม่สามารถอ้างอิงได้อย่างชัดเจน ตัวอย่างเช่น "ไม่สามารถแก้ไขข้อมูลอ้างอิงนี้ไม่พบแอสเซมบลี" Data .... ""

ไม่มีใครรู้วิธีที่ดีกว่านี้?


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

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

คำเตือน "#warning" ตามตัวอักษรยังไม่ซ้ำกัน ฉันมักจะต้องการตรวจสอบ แต่ฉันไม่ต้องการทำลายงานสร้าง


คุณช่วยใส่ช่องว่างในรายการตัวเลขจำนวนมากได้ไหม มีการยัดเส้นห่อ
Ray

Gawd ฉันเกลียดกฎเกณฑ์ที่ซับซ้อนซึ่งสร้างขึ้นโดยผู้คนบ่อยครั้งเพื่อบรรเทาอัตตาของบุคคลบางคน
Jon Limjap

21
ฉันเห็นประเด็นของเขาเกี่ยวกับคำเตือนที่ล้าสมัยนี่ไม่ใช่เรื่องที่กำหนด
Ed S.

จากประสบการณ์ของฉันการอนุญาตแม้แต่คำเตือนเดียวในบิลด์ของคุณก็เหมือนกับการเพิ่ม async / await ครั้งแรก อีกไม่นานจะมีพวกมันหลายสิบตัว ในการตั้งค่าทั้งหมดฉันจำได้ว่านักพัฒนาสามารถเห็นคำเตือนน้อยกว่า 10 คำเตือนในหน้าต่างรายการข้อผิดพลาดใน VS. ฉันสามารถเดิมพันได้ว่าเท่าที่คุณมีคำเตือนมากกว่า 5 คำเตือนส่วนใหญ่ของ devs ในทีมจะไม่สามารถมองเห็นสิ่งใหม่ได้ - ในการตั้งค่าของคุณนั่นหมายความว่าพวกเขาจะไม่สังเกตเห็นคำเตือนว่าวิธีการนั้นล้าสมัยซึ่งท้าทาย จุดประสงค์ทั้งหมดของการเตือน :) คุณมีประสบการณ์อะไรกับนีล?
tymtam

@mayu มันเป็นปริศนา หลายครั้งฉันเห็นคำเตือนถูกละเลยมาเป็นเวลานาน แต่สุดท้ายแล้วไม่ว่าคุณจะแสดงคำเตือนหรือคุณไม่แสดงอะไรเลย หากคุณกำลังแสดงคำเตือนอย่างน้อยก็มีโอกาสที่จะมีคนเรียนรู้สิ่งที่เป็นประโยชน์จากมัน หากคุณถือว่าคำเตือนส่วนใหญ่เป็นข้อผิดพลาดสิ่งที่เหลืออยู่จะได้รับความสนใจมากขึ้น
Neil

คำตอบ:


155

คุณสามารถเพิ่มWarningsNotAsErrors-tag ในไฟล์โครงการ

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

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


24
ความแตกต่างระหว่าง 612 และ 618 คือความคิดเห็นของ ObsoleteAttribute ObsoleteAttribute ที่ไม่มีความคิดเห็นจะสร้างข้อผิดพลาด 612 และอีกรายการที่มีความคิดเห็นสร้าง 618
Marco Spatz

@MarcoSpatz แน่นอน จากนั้นเราก็สามารถรักษา[Obsolete]สมาชิกที่messageเป็นnullข้อผิดพลาดในขณะที่เราปล่อยให้ผู้ที่messageถูกตั้งค่ายังคงคำเตือนเท่านั้น หากตั้งerrorค่าพารามิเตอร์เป็นtrueในObsoleteAttributeCS0619 จะถูกสร้างขึ้นแทน ดูเหมือนว่าจะไม่ได้ผลถ้าmessageเป็นnull(แต่ใครจะทำ[Obsolete(null, true)]ล่ะ)
Jeppe Stig Nielsen

สำหรับ F # ให้ใช้--warnaserror-:618,1030ในฟิลด์ Build-> Other แฟล็ก ตัวเลือกโครงการนี้ยังไม่ได้ใช้กับโครงการ F # github.com/Microsoft/visualfsharp/issues/3395
Asik

2
สิ่งที่ควรทราบมี "WarningsNotAsErrors" อยู่ ควรมีอยู่ในการตั้งค่าโครงการโดยไม่ต้องแก้ไขไฟล์ด้วยตนเอง ขอบคุณ
หลัง

1
Microsoft ทำสิ่งนี้ผิดพลาดจริงๆ (และ 11 ปีต่อมายังไม่ได้แก้ไขสิ่งต่าง ๆ !) การตั้งค่าโปรเจ็กต์เปลี่ยน<NoWarn>ไปซึ่งส่วนใหญ่จะด้อยกว่าและไม่สามารถใส่<WarningsNotAsErrors>UI ได้ ความรุ่งโรจน์
user2864740

13

/ warnaserror / warnaserror-: 618


1
ขอบคุณสำหรับข้อมูลของคุณ แม้ว่าจะไม่สามารถแก้ปัญหา IDE ได้ แต่ความคิดเห็นเหล่านี้เป็นประโยชน์มากที่สุด
Neil

2
คุณจะเพิ่มสิ่งนี้ได้ที่ไหน
checho

@checho สวิตช์เหล่านั้นจะถูกเพิ่มในบรรทัดคำสั่งเมื่อเรียก msbuild สำหรับวัตถุประสงค์ของเราคำตอบด้านบนมีประโยชน์มากกว่าเพราะเราสามารถอบมันลงในโครงการแทนที่จะต้องแก้ไขวิธีที่เราเรียกว่า msbuild
Neil

ไม่ทำงานกับ MSBuild 15.9.21 + g9802d43bc3: MSBUILD : error MSB1001: Unknown switch. Switch: /warnaserror-:618
Paul B.

3

หรือโดยเฉพาะอย่างยิ่งในกรณีของคุณ:

/ warnaserror / warnaserror-: 612,1030,1701,1702

สิ่งนี้ควรถือว่าคำเตือนทั้งหมดเป็นข้อผิดพลาดยกเว้นคำเตือนในรายการที่คั่นด้วยจุลภาคของคุณ


1

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

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

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


7
คำเตือนส่วนใหญ่เกิดขึ้นเนื่องจากความสับสนในโค้ดของฉัน (เช่นฉันประกาศตัวแปรที่ฉันไม่ได้ใช้) คำเตือนล้าสมัยมักเกิดขึ้นเนื่องจากมีการเปลี่ยนแปลงรหัสของผู้อื่น การแก้ไขปัญหานี้อาจใช้เวลาหลายสัปดาห์ในการพัฒนา # คำเตือนคือคำเตือนที่ฉันต้องการในโค้ด (น่าจะเป็นการแก้ไขระยะยาว)
นีล

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

@ นีลฉันเห็นด้วยกับข้อโต้แย้งของคุณ แต่การลบตัวแปรที่คุณไม่ได้ใช้นั้นไม่ได้ใช้เวลามากและคุณต้องการทราบอย่างแน่นอนว่าทีมอื่นทำสิ่งที่ล้าสมัย
tymtam

@mayu ขอบคุณสำหรับความคิดเห็นของคุณ ฉันยอมรับเกี่ยวกับตัวแปรที่คุณไม่ได้ใช้ นั่นเป็นเหตุผลที่ฉันจะให้คอมไพเลอร์ถือว่าเป็นข้อผิดพลาด ฉันยอมรับด้วยว่าคุณต้องการทราบเมื่อมีบางอย่างล้าสมัย แต่หากต้องใช้เวลานานในการ refactor บางอย่างที่ล้าสมัยในโค้ดของคุณตัวเลือกของคุณคือ 1) ถือว่าคำเตือนนี้เป็นคำเตือน 2) ปล่อยให้บิวด์ของคุณพังเป็นเวลานาน 3) วิธีแก้ปัญหาอื่น ๆ เช่นการปิดคำเตือนเป็นข้อผิดพลาด เนื่องจากคำเตือนส่วนใหญ่เป็นข้อผิดพลาดรายการคำเตือนของคุณมีแนวโน้มที่จะสั้นดังนั้นคุณจึงมีแนวโน้มที่จะสังเกตเห็นได้มากขึ้นเมื่อคำเตือนปรากฏขึ้น ทางออกที่คุณต้องการคืออะไร?
Neil

1
@mayu ทีมอื่น (ไม่ว่าจะอยู่ใน บริษัท เดียวกันหรือภายนอก) อาจต้องการสื่อสารอย่างถูกต้องว่าคลาสวิธีการส่วนประกอบอื่น ๆ กำลังถูกยกเลิกไปในช่วงระยะเวลาหนึ่ง การเพิ่มแอตทริบิวต์เป็นวิธีที่ดีในการส่งสัญญาณนี้ไปยังผู้ใช้ห้องสมุด ฉันไม่เห็นว่ามันเป็นเรื่องยุ่งยากที่จะทำเช่นนี้ ในความเป็นจริงการเพิ่มแอตทริบิวต์โดยเร็วที่สุดเป็นวิธีที่ดีที่จะทำให้ผู้อื่นทราบถึงการเปลี่ยนแปลงในอนาคต
นีล

1

ฉันใช้คำเตือนถือว่าเป็นข้อผิดพลาด

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

การมีอยู่ของคำสั่งนี้ยังช่วยให้ค้นหาได้ว่าใครยอมรับการละเมิดคำเตือนนี้ (โดยการกระทำ "ตำหนิ" ของการควบคุมเวอร์ชัน) ในกรณีที่มีคำถามบางอย่าง


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

0

ทำไมไม่เพียง แต่มีกฎว่า "ใครก็ตามที่เช็คอินโค้ดโดยมีคำเตือนใด ๆ อยู่ข้างในนอกเหนือจาก 612, 1030, 1701 หรือ 1702 ในนั้นจะต้องไปที่ไวท์บอร์ดและเขียนเป็นร้อย ๆ ครั้ง 'ฉันจะไม่เช็คอินโค้ดพร้อมคำเตือนที่ไม่อนุญาตอีก '"


9
ขอให้โชคดีที่บังคับว่า ... การปฏิบัติต่อคำเตือนเนื่องจากข้อผิดพลาดเป็นขั้นตอนที่สำคัญมากในการเพิ่มคุณภาพโค้ดโดยรวม และจะบังคับให้ devs แก้ไขโค้ดของตนจริง ๆ ! อัตโนมัติลูกเห็บทั้งหมด, ผู้ใช้แรงงานคือเพื่อศตวรรษที่ 20: ish!
Andreas Magnusson

@AndreasMagnusson หากขาดเพียงคำเตือนจริง ๆ รับรองคุณภาพของรหัส ..
user2864740

2
@ user2864740: ตกลงไม่มีกระสุนเงิน แต่มันเป็นความเข้าใจผิดที่พบบ่อยเกินไปที่จะปฏิเสธสิ่งที่มีประโยชน์โดยอ้างว่าไม่ใช่กระสุนเงิน
Andreas Magnusson


-4

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

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


1
การใช้คำตอบที่เลือกทำให้ง่ายต่อการเพิ่มลงในรายการคำเตือนที่ถือว่าเป็นคำเตือน ทำงานได้ดีกว่าโซลูชันที่คุณเสนอไว้มาก คำเตือนอย่างชัดเจนไม่ใช่ข้อผิดพลาด แต่การปฏิบัติต่อคำเตือนส่วนใหญ่เป็นข้อผิดพลาดหมายความว่าโค้ดจะไม่ถูกตรวจสอบพร้อมคำเตือนเหล่านั้น
Neil
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.