iOS+
Android
Flutter
Unity
หน้านี้ให้ความช่วยเหลือในการแก้ปัญหาและคำตอบสำหรับคำถามที่พบบ่อยเกี่ยวกับการใช้ Crashlytics หากไม่พบสิ่งที่ต้องการหรือต้องการความช่วยเหลือเพิ่มเติม โปรดติดต่อทีมสนับสนุน Firebase
การแก้ปัญหาทั่วไป/คำถามที่พบบ่อย
ไม่เห็นเมตริกและ/หรือการแจ้งเตือนเกี่ยวกับความเร็วที่ไม่มีข้อขัดข้อง
หากไม่เห็นเมตริกที่ไม่มีการขัดข้อง (เช่น ผู้ใช้และเซสชันที่ไม่มีการขัดข้อง) และ/หรือการแจ้งเตือนเกี่ยวกับความเร็ว ให้ตรวจสอบว่าคุณใช้
Crashlytics SDK 11.7.0 ขึ้นไป
ไม่เห็นบันทึกเบรดครัมบ์
หากไม่เห็นบันทึกเบรดครัมบ์ เราขอแนะนำให้ตรวจสอบการกําหนดค่าแอปเพื่อหา Google Analytics
โปรดตรวจสอบว่าคุณมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้
การเห็นสแต็กเทรซที่ไม่มีสัญลักษณ์สําหรับแอป Android ในหน้าแดชบอร์ด Crashlytics
หากคุณใช้ Unity IL2CPP และเห็นสแต็กเทรซที่ไม่มีสัญลักษณ์ ให้ลองทำดังนี้
ตรวจสอบว่าคุณใช้ Crashlytics Unity
SDK เวอร์ชัน 8.6.1 ขึ้นไป
ตรวจสอบว่าคุณได้ตั้งค่าและเรียกใช้คำสั่ง Firebase CLI
crashlytics:symbols:upload เพื่อสร้างและอัปโหลดไฟล์สัญลักษณ์แล้ว
คุณต้องเรียกใช้คําสั่ง CLI นี้ทุกครั้งที่สร้างบิวด์รุ่นหรือบิวด์ที่ต้องการดูสแต็กเทรซที่แปลงสัญลักษณ์ในคอนโซล Firebase ดูข้อมูลเพิ่มเติมได้ในหน้าดูรายงานข้อขัดข้องที่อ่านได้
Crashlytics ใช้กับแอปที่ใช้ IL2CPP ได้ไหม
ได้ Crashlytics สามารถแสดงสแต็กเทรซที่มีสัญลักษณ์สําหรับแอปที่ใช้ IL2CPP ความสามารถนี้พร้อมใช้งานสำหรับแอปที่เผยแพร่ในแพลตฟอร์ม Android หรือ Apple สิ่งที่คุณต้องทํามีดังนี้
ตรวจสอบว่าคุณใช้ Crashlytics Unity
SDK เวอร์ชัน 8.6.0 ขึ้นไป
ทํางานที่จําเป็นสําหรับแพลตฟอร์มให้เสร็จสมบูรณ์
สำหรับแอปบนแพลตฟอร์ม Apple : คุณไม่ต้องดำเนินการใดๆ เป็นพิเศษ สําหรับแอปแพลตฟอร์ม Apple ปลั๊กอิน Firebase Unity Editor จะกําหนดค่าโปรเจ็กต์ Xcode ให้อัปโหลดสัญลักษณ์โดยอัตโนมัติ
สำหรับแอป Android : ตรวจสอบว่าคุณได้ตั้งค่าและเรียกใช้คำสั่ง Firebase CLI crashlytics:symbols:upload เพื่อสร้างและอัปโหลดไฟล์สัญลักษณ์แล้ว
คุณต้องเรียกใช้คําสั่ง CLI นี้ทุกครั้งที่สร้างบิวด์รุ่นหรือบิวด์ที่ต้องการดูสแต็กเทรซที่แปลงสัญลักษณ์ในคอนโซล Firebase ดูข้อมูลเพิ่มเติมได้ในหน้าดูรายงานข้อขัดข้องที่อ่านได้
ระบบคำนวณผู้ใช้ที่ไม่พบข้อขัดข้องอย่างไร
ค่า "ไม่พบข้อขัดข้อง" แสดงเปอร์เซ็นต์ของผู้ใช้ที่มีส่วนร่วมกับแอปแต่ไม่
สูตรการคำนวณเปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องมีดังนี้ Google Analytics จะเป็นผู้ระบุค่าอินพุต
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS ) x 100
เมื่อเกิดข้อขัดข้อง Google Analytics จะส่งเหตุการณ์ประเภท app_exception และ CRASHED_USERS จะแสดงจํานวนผู้ใช้ที่เชื่อมโยงกับเหตุการณ์ประเภทนั้น
ALL_USERS แสดงจํานวนผู้ใช้ทั้งหมดที่มีส่วนร่วมกับแอปของคุณในระยะเวลาที่คุณเลือกจากเมนูแบบเลื่อนลงที่ด้านขวาบนของหน้าแดชบอร์ด Crashlytics
หมายเหตุ: หากต้องการคํานวณเปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้องของแอปด้วยตนเอง ให้ดูจํานวนเหตุการณ์ app_exception สําหรับแอปในแดชบอร์ด Analytics อย่างไรก็ตาม เนื่องจากความแตกต่างเล็กน้อยในวิธีประมวลผลข้อขัดข้อง ค่า app_exception ที่แสดงในหน้าแดชบอร์ด Analytics จึงอาจแตกต่างจากค่าที่เราใช้ในการคํานวณเปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้อง เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือการรวบรวมข้อมูลเมื่อเวลาผ่านไป ไม่ใช่ค่าเฉลี่ย
ตัวอย่างเช่น สมมติว่าแอปของคุณมีผู้ใช้ 3 ราย เราจะเรียกผู้ใช้เหล่านั้นว่าผู้ใช้ ก ผู้ใช้ ข และผู้ใช้ ค ตารางต่อไปนี้แสดงผู้ใช้ที่มีส่วนร่วมกับแอปในแต่ละวัน และผู้ใช้รายใดที่พบข้อขัดข้องในวันนั้น
จันทร์
อังคาร
พุธ
ผู้ใช้ที่มีส่วนร่วมกับแอปของคุณ
A, B, C
A, B, C
A, B
ผู้ใช้ที่พบการขัดข้อง
C
B
A
ในวันพุธ เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือ 50% (ผู้ใช้ 1 ใน 2 คนไม่พบข้อขัดข้อง)ผู้ใช้ 2 คนมีส่วนร่วมกับแอปของคุณในวันพุธ แต่มีเพียงผู้ใช้รายเดียว (ผู้ใช้ ข.) ที่ไม่พบข้อขัดข้อง
ในช่วง 2 วันที่ผ่านมา เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือ 33.3% (ผู้ใช้ 1 ใน 3 ไม่พบข้อขัดข้อง)ผู้ใช้ 3 คนมีส่วนร่วมกับแอปในช่วง 2 วันที่ผ่านมา แต่มีเพียงผู้ใช้รายเดียว (ผู้ใช้ ค) ที่ไม่พบข้อขัดข้อง
ในช่วง 3 วันที่ผ่านมา เปอร์เซ็นต์ของผู้ใช้ที่ไม่พบข้อขัดข้องคือ 0% (ผู้ใช้ 0 รายจาก 3 รายที่ไม่พบข้อขัดข้อง)ผู้ใช้ 3 รายมีส่วนร่วมกับแอปในช่วง 3 วันที่ผ่านมา แต่ ไม่มีผู้ใช้รายใดพบข้อขัดข้อง
ไม่ควรเปรียบเทียบค่าผู้ใช้ที่ไม่ได้รับผลจากความขัดข้องในช่วงเวลาต่างๆ
ความน่าจะเป็นที่ผู้ใช้รายหนึ่งจะพบข้อขัดข้องจะเพิ่มขึ้นเมื่อผู้ใช้ใช้แอปของคุณบ่อยขึ้น ดังนั้นค่าผู้ใช้ที่ไม่พบข้อขัดข้องจึงมีแนวโน้มที่จะลดลงเมื่อระยะเวลานานขึ้น
หมายเหตุ: คุณจะเห็นการ์ดสถิติที่ไม่มีการขัดข้อง ว่างเปล่าหากกรองประเภทเหตุการณ์ เป็นปัญหาที่ไม่ร้ายแรงเท่านั้น ระบบจะคํานวณเปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้องสําหรับเหตุการณ์ร้ายแรงเท่านั้น
ใครดู เขียน และลบหมายเหตุเกี่ยวกับปัญหาได้บ้าง
หมายเหตุช่วยให้สมาชิกโปรเจ็กต์แสดงความคิดเห็นเกี่ยวกับปัญหาที่เฉพาะเจาะจงได้ พร้อมคำถาม สถานะ การอัปเดต ฯลฯ
เมื่อสมาชิกในโปรเจ็กต์โพสต์โน้ต ระบบจะติดป้ายกำกับโน้ตด้วยอีเมลของบัญชี Google อีเมลนี้และโน้ตจะแสดงให้สมาชิกโปรเจ็กต์ทุกคนที่มีสิทธิ์ดูโน้ตเห็น
สิทธิ์เข้าถึงที่จําเป็นในการดู เขียน และลบโน้ตมีดังนี้
ใครดู เขียน และลบหมายเหตุเกี่ยวกับปัญหาได้บ้าง
หมายเหตุช่วยให้สมาชิกโปรเจ็กต์แสดงความคิดเห็นเกี่ยวกับปัญหาที่เฉพาะเจาะจงได้ พร้อมคำถาม สถานะ การอัปเดต ฯลฯ
เมื่อสมาชิกในโปรเจ็กต์โพสต์โน้ต ระบบจะติดป้ายกำกับโน้ตด้วยอีเมลของบัญชี Google อีเมลนี้และโน้ตจะแสดงให้สมาชิกโปรเจ็กต์ทุกคนที่มีสิทธิ์ดูโน้ตเห็น
สิทธิ์เข้าถึงที่จําเป็นในการดู เขียน และลบโน้ตมีดังนี้
การผสานรวม
แอปใช้ Google Mobile Ads SDK ด้วย แต่ไม่มีการขัดข้อง
หากโปรเจ็กต์ใช้ Crashlytics ร่วมกับ SDK ของ Google Mobile Ads ก็มีความเป็นไปได้ว่าเครื่องมือรายงานข้อขัดข้องจะรบกวนเมื่อลงทะเบียนตัวแฮนเดิลข้อยกเว้น หากต้องการแก้ไขปัญหา ให้ปิดการรายงานข้อขัดข้องใน Mobile Ads SDK โดยเรียกใช้ disableSDKCrashReporting
ชุดข้อมูล BigQuery ของฉันอยู่ที่ไหน
หลังจากลิงก์ Crashlytics กับ BigQuery แล้ว ชุดข้อมูลใหม่ที่สร้างขึ้นจะอยู่ในสหรัฐอเมริกาโดยอัตโนมัติ ไม่ว่าโปรเจ็กต์ Firebase จะอยู่ที่ไหนก็ตาม
ปัญหาเดิม
ปัญหาที่ลดลงคืออะไร
ปัญหากลับมาเกิดขึ้นอีกเมื่อคุณปิดปัญหาไปแล้วก่อนหน้านี้ แต่Crashlytics ได้รับรายงานใหม่ว่าปัญหาเกิดขึ้นอีกครั้ง
Crashlytics จะเปิดปัญหาที่กลับมาอีกครั้งเหล่านี้ขึ้นใหม่โดยอัตโนมัติเพื่อให้คุณแก้ไขตามความเหมาะสมสำหรับแอปของคุณ
ต่อไปนี้เป็นตัวอย่างสถานการณ์ที่อธิบายวิธีที่ Crashlytics จัดหมวดหมู่ปัญหาเป็นการถดถอย
Crashlytics ได้รับรายงานข้อขัดข้องเกี่ยวกับข้อขัดข้อง "A" เป็นครั้งแรก Crashlytics เปิดปัญหาที่เกี่ยวข้องสำหรับการขัดข้องนั้น (ปัญหา "ก")คุณแก้ไขข้อบกพร่องนี้อย่างรวดเร็ว ปิดปัญหา "ก" แล้วเผยแพร่แอปเวอร์ชันใหม่
Crashlytics ได้รับรายงานอีกฉบับเกี่ยวกับปัญหา "ก" หลังจากที่คุณปิดปัญหาแล้ว
หากรายงานมาจากเวอร์ชันแอปที่ Crashlytics ทราบ เมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันดังกล่าวได้ส่งรายงานข้อขัดข้องสำหรับข้อขัดข้องใดๆ ก็ตาม) Crashlytics จะไม่ถือว่าปัญหาดังกล่าวแย่ลง ปัญหาจะยังคงปิดอยู่
หากรายงานมาจากเวอร์ชันแอปที่ Crashlytics ไม่ ล่วงรู้ไม่เคย ส่งรายงานข้อขัดข้องใดๆ เกี่ยวกับข้อขัดข้องใดๆ เลย) Crashlytics จะถือว่าปัญหากลับมาอีกครั้งและจะเปิดปัญหาดังกล่าวขึ้นมาใหม่
หมายเหตุ: ก่อนเดือนกุมภาพันธ์ 2022 Crashlytics จะจัดหมวดหมู่ปัญหาเป็นการถดถอยเมื่อปัญหานั้นเกิดขึ้นอีกครั้งในเวอร์ชันใดก็ได้ ของแอป แม้จะเป็นเวอร์ชันที่เราทราบเมื่อคุณปิดปัญหาแล้วก็ตาม ส่งผลให้ Crashlytics ระบุการถดถอยอย่างไม่ถูกต้องในบางครั้ง ตอนนี้เราใช้รูปแบบที่อธิบายไว้ด้านบน เมื่อปัญหากลับมาเกิดขึ้นอีก เราจะส่งการแจ้งเตือนการตรวจหาการเกิดซ้ำและเพิ่มสัญญาณการเกิดซ้ำลงในปัญหาเพื่อแจ้งให้ทราบว่า Crashlytics ได้เปิดปัญหาขึ้นมาอีกครั้ง หากไม่ต้องการให้ระบบเปิดปัญหาขึ้นมาอีกครั้งเนื่องจากอัลกอริทึมการถดถอย ให้ "ปิดเสียง" ปัญหาแทนการปิด
เหตุใดฉันจึงเห็นปัญหาที่เพิ่มขึ้นสำหรับแอปเวอร์ชันเก่า
หากรายงานมาจากแอปเวอร์ชันเก่าที่ไม่เคยส่งรายงานข้อขัดข้องเลยเมื่อคุณปิดปัญหา Crashlytics จะถือว่าปัญหากลับมาอีกครั้งและจะเปิดปัญหานั้นขึ้นมาใหม่
กรณีนี้อาจเกิดขึ้นได้เมื่อคุณแก้ไขข้อบกพร่องและเปิดตัวแอปเวอร์ชันใหม่แล้ว แต่ยังมีผู้ใช้ที่ใช้แอปเวอร์ชันเก่าอยู่ซึ่งไม่มีการแก้ไขข้อบกพร่อง หากเวอร์ชันเก่าเวอร์ชันใดเวอร์ชันหนึ่งไม่เคย ส่งรายงานข้อขัดข้องเมื่อคุณปิดปัญหา และผู้ใช้เหล่านั้นเริ่มพบข้อบกพร่อง รายงานข้อขัดข้องเหล่านั้นจะทริกเกอร์ปัญหาที่กลับมาอีกครั้ง
หากไม่ต้องการให้ระบบเปิดปัญหาขึ้นมาอีกครั้งเนื่องจากอัลกอริทึมการถดถอยของเรา ให้ "ปิดเสียง" ปัญหาแทนการปิด
หมายเหตุ: ก่อนเดือนกุมภาพันธ์ 2022 Crashlytics จะจัดหมวดหมู่ปัญหาเป็นการถดถอยเมื่อปัญหานั้นเกิดขึ้นอีกครั้งในเวอร์ชันแอปใดก็ตาม แม้ว่าจะเป็นเวอร์ชันที่เราทราบเมื่อคุณปิดปัญหาก็ตาม ส่งผลให้ Crashlytics
ระบุการถดถอยอย่างไม่ถูกต้องในบางครั้ง ตอนนี้เราใช้รูปแบบที่อธิบายไว้ด้านบน
การรายงานข้อยกเว้นที่ตรวจไม่พบเป็นข้อยกเว้นร้ายแรง Crashlytics สามารถรายงานข้อยกเว้นที่ตรวจไม่พบว่าเป็นข้อผิดพลาดร้ายแรงได้ (ตั้งแต่ v10.4.0 ของ Unity SDK เป็นต้นไป) คําถามที่พบบ่อยต่อไปนี้จะช่วยอธิบายเหตุผลและแนวทางปฏิบัติแนะนําในการใช้ฟีเจอร์นี้
เหตุใดแอปจึงควรรายงานข้อยกเว้นที่ตรวจไม่พบว่าเป็นข้อยกเว้นร้ายแรง
การรายงานข้อยกเว้นที่ตรวจไม่พบเป็นข้อยกเว้นร้ายแรงจะช่วยให้คุณทราบข้อยกเว้นที่อาจส่งผลให้เล่นเกมไม่ได้อย่างสมจริงมากขึ้น แม้ว่าแอปจะยังคงทำงานต่อไป
โปรดทราบว่าหากคุณเริ่มรายงานข้อขัดข้องร้ายแรง เปอร์เซ็นต์ผู้ใช้ที่ไม่พบข้อขัดข้อง (CFU) มีแนวโน้มที่จะลดลง แต่เมตริก CFU จะแสดงถึงประสบการณ์ของผู้ใช้ปลายทางกับแอปของคุณได้มากกว่า
สำคัญ: การรายงานข้อยกเว้นที่ตรวจไม่พบว่าเป็นข้อยกเว้นร้ายแรงจะไม่ Android Vitals
ข้อผิดพลาดร้ายแรงที่รายงานใน Crashlytics จะเป็นข้อมูลที่คุณเห็นเท่านั้นเพื่อให้คุณค้นพบและแก้ไขปัญหาในแอปและเกมได้
ข้อยกเว้นใดบ้างที่ระบบจะรายงานเป็นข้อยกเว้นร้ายแรง
Crashlytics จะรายงานข้อยกเว้นที่ตรวจไม่พบว่าเป็นข้อยกเว้นร้ายแรงได้ก็ต่อเมื่อเป็นไปตามเงื่อนไขทั้ง 2 ข้อต่อไปนี้
ในระหว่างการเริ่มต้นใช้งานในแอป คุณต้องตั้งค่าพร็อพเพอร์ตี้ ReportUncaughtExceptionsAsFatal ให้มีค่าเป็น true
แอปของคุณ (หรือไลบรารีที่รวมไว้) แสดงข้อยกเว้นที่ไม่ได้จับ ระบบจะไม่ถือว่าข้อยกเว้นที่สร้างขึ้นแต่ไม่ได้แสดง เป็นข้อยกเว้นที่ไม่มีการจับ
หลังจากเปิดใช้การรายงานข้อยกเว้นที่ตรวจไม่พบเป็นข้อยกเว้นร้ายแรง ตอนนี้ฉันมีข้อยกเว้นร้ายแรงใหม่จำนวนมาก ฉันจะจัดการข้อยกเว้นเหล่านี้อย่างเหมาะสมได้อย่างไร
เมื่อเริ่มได้รับรายงานข้อยกเว้นที่ตรวจไม่พบเป็นข้อยกเว้นร้ายแรง ตัวเลือกการจัดการข้อยกเว้นที่ตรวจไม่พบเหล่านี้มีดังนี้
จับและจัดการข้อยกเว้นที่โยน ระบบจะสร้างและแสดงข้อยกเว้นเพื่อแสดงสถานะที่ผิดปกติหรือที่ไม่คาดคิด
การแก้ปัญหาที่แสดงโดยข้อยกเว้นที่โยนนั้นเกี่ยวข้องกับการทำให้โปรแกรมกลับคืนสู่สถานะที่รู้จัก (กระบวนการที่เรียกว่าการจัดการข้อยกเว้น
แนวทางปฏิบัติแนะนำคือให้จับและจัดการข้อยกเว้นที่คาดการณ์ไว้ทั้งหมด เว้นแต่โปรแกรมจะไม่สามารถกลับไปยังสถานะที่รู้จัก
หากต้องการควบคุมประเภทข้อยกเว้นที่โค้ดจะจับและจัดการ ให้รวมโค้ดที่อาจสร้างข้อยกเว้นไว้ในบล็อก try-catch
ตรวจสอบว่าเงื่อนไขในคำสั่ง catch นั้นแคบที่สุดเท่าที่จะเป็นไปได้เพื่อจัดการข้อยกเว้นที่เฉพาะเจาะจงอย่างเหมาะสม
บันทึกข้อยกเว้นใน Unity หรือ Crashlytics การบันทึกข้อยกเว้นใน Unity หรือ Crashlytics เพื่อช่วยแก้ไขข้อผิดพลาดทำได้หลายวิธี
เมื่อใช้ Crashlytics ตัวเลือกที่พบบ่อยที่สุดและแนะนํามี 2 ตัวเลือกดังนี้
ตัวเลือกที่ 1: พิมพ์ในคอนโซล Unity แต่ไม่ต้องรายงานไปยัง Crashlytics ระหว่างการพัฒนาหรือการแก้ปัญหา
พิมพ์ไปยังคอนโซล Unity โดยใช้ Debug.Log(exception),
Debug.LogWarning(exception) และ Debug.LogError(exception) ซึ่งจะพิมพ์เนื้อหาของข้อยกเว้นไปยังคอนโซล Unity และไม่แสดงข้อยกเว้นอีกครั้ง
ตัวเลือกที่ 2: อัปโหลดไปยัง Crashlytics สำหรับการรายงานแบบรวมในแดชบอร์ด Crashlytics สำหรับสถานการณ์ต่อไปนี้
หากข้อยกเว้นควรบันทึกเพื่อแก้ไขข้อบกพร่องของเหตุการณ์ Crashlytics ที่อาจเกิดขึ้นในภายหลัง ให้ใช้ Crashlytics.Log(exception.ToString())
หากยังคงต้องรายงานข้อยกเว้นไปยัง Crashlytics แม้ว่าจะมีการจับและจัดการแล้ว ให้ใช้ Crashlytics.LogException(exception) เพื่อบันทึกเป็นเหตุการณ์ที่ไม่ร้ายแรง
อย่างไรก็ตาม หากต้องการรายงานเหตุการณ์ร้ายแรงไปยัง Unity Cloud Diagnostic ด้วยตนเอง ให้ใช้ Debug.LogException ตัวเลือกนี้จะแสดงข้อยกเว้นในคอนโซล Unity เช่นเดียวกับตัวเลือกที่ 1 แต่จะแสดงข้อยกเว้นด้วย (ไม่ว่าจะมีการแสดงหรือจับข้อยกเว้นไว้แล้วหรือไม่ก็ตาม) แต่จะแสดงข้อผิดพลาดแบบไม่แสดงในหน้า ซึ่งหมายความว่าแม้ Debug.LogException(exception)
ที่มีบล็อก try-catch อยู่รอบๆ ก็จะยังคงทำให้เกิดข้อยกเว้นที่ตรวจไม่พบ
ดังนั้น ให้เรียกใช้ Debug.LogException เฉพาะในกรณีที่คุณต้องการทำทั้งหมด
วิธีพิมพ์ข้อยกเว้นไปยังคอนโซล Unity
วิธีอัปโหลดข้อยกเว้นไปยัง Crashlytics เป็นเหตุการณ์ร้ายแรง
หากต้องการแสดงข้อยกเว้น ให้ถือว่าข้อยกเว้นนั้นเป็นข้อยกเว้นที่ตรวจไม่พบ และรายงานไปยัง Unity Cloud Diagnostics
โปรดทราบว่าหากต้องการพิมพ์ข้อยกเว้นที่พบในคอนโซล Unity และ Crashlytics เป็นเหตุการณ์ที่ไม่ร้ายแรง ให้ทําดังนี้แทน
try
{
methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
// Print the exception to the Unity console at the error level.
Debug.LogError(exception);
// Upload the exception to Crashlytics as a non-fatal event.
Crashlytics.LogException(exception); // not Debug.LogException
//
// Code that handles the exception
//
}
