การเรียนรู้ข้อความแสดงข้อผิดพลาดของ TypeScript อย่างเชี่ยวชาญ: การสร้างประเภทข้อผิดพลาดแบบกำหนดเองสำหรับแอปพลิเคชันที่แข็งแกร่ง

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

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

เหตุใดประเภทข้อผิดพลาดแบบกำหนดเองจึงมีความสำคัญในการพัฒนาระดับโลก

ก่อนที่เราจะเจาะลึก 'วิธีการ' มากำหนด 'เหตุผล' กันก่อน เหตุใดนักพัฒนา โดยเฉพาะอย่างยิ่งผู้ที่ทำงานในทีมระหว่างประเทศหรือให้บริการฐานผู้ใช้ทั่วโลก จึงควรลงทุนเวลาในประเภทข้อผิดพลาดแบบกำหนดเอง? เหตุผลมีมากมาย:

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

ทำความเข้าใจพื้นฐานการจัดการข้อผิดพลาดของ TypeScript

TypeScript ใช้ประโยชน์จากกลไกการจัดการข้อผิดพลาดพื้นฐานของ JavaScript โดยส่วนใหญ่จะใช้บล็อก try...catch...finally และออบเจ็กต์ Error ออบเจ็กต์ Error มาตรฐานใน JavaScript มีคุณสมบัติหลักสองสามอย่าง:

• message: คำอธิบายข้อผิดพลาดที่มนุษย์อ่านได้
• name: ชื่อของประเภทข้อผิดพลาด (เช่น 'Error', 'TypeError')
• stack: สตริงที่มี call stack ณ จุดที่เกิดข้อผิดพลาด

เมื่อคุณโยนข้อผิดพลาดทั่วไปใน TypeScript อาจมีลักษณะดังนี้:

            
function processData(data: any) {
  if (!data || typeof data !== 'object') {
    throw new Error('Invalid data provided. Expected an object.');
  }
  // ... process data
}

try {
  processData(null);
} catch (error) {
  console.error(error.message);
}

            

              
                Copy
              
            
          

แม้ว่าวิธีนี้จะได้ผล แต่ข้อความแสดงข้อผิดพลาด 'Invalid data provided. Expected an object.' นั้นค่อนข้างทั่วไป จะเกิดอะไรขึ้นถ้ามีข้อมูลที่ไม่ถูกต้องหลายประเภท จะเกิดอะไรขึ้นถ้าเราต้องการแยกความแตกต่างระหว่างพารามิเตอร์ที่หายไปและพารามิเตอร์ที่ผิดรูปแบบ

การใช้งานประเภทข้อผิดพลาดแบบกำหนดเองครั้งแรกของคุณ

วิธีที่พบบ่อยและมีประสิทธิภาพที่สุดในการสร้างประเภทข้อผิดพลาดแบบกำหนดเองใน TypeScript คือการขยายคลาส Error ในตัว วิธีนี้ช่วยให้ข้อผิดพลาดแบบกำหนดเองของคุณสืบทอดคุณสมบัติทั้งหมดของออบเจ็กต์ข้อผิดพลาดมาตรฐาน ในขณะที่ช่วยให้คุณเพิ่มคุณสมบัติและวิธีการเฉพาะของคุณเองได้

คลาสข้อผิดพลาดแบบกำหนดเองพื้นฐาน

มาเริ่มต้นด้วยข้อผิดพลาดแบบกำหนดเองง่ายๆ เช่น ValidationError เพื่อแสดงถึงปัญหาเกี่ยวกับการตรวจสอบความถูกต้องของข้อมูล

            
class ValidationError extends Error {
  constructor(message: string) {
    super(message); // Call the parent constructor (Error)
    this.name = 'ValidationError'; // Set the name of the error

    // Maintains proper stack trace for where our error was thrown (only available on V8)
    if (Error.captureStackTrace) {
      Error.captureStackTrace(this, ValidationError);
    }
  }
}

            

              
                Copy
              
            
          

คำอธิบาย:

• เรากำหนดคลาส ValidationError ที่ extends Error
• constructor รับสตริง message ซึ่งถูกส่งไปยังการเรียก super() นี่เป็นการเริ่มต้นคลาส Error ฐานด้วยข้อความ
• เราตั้งค่า this.name = 'ValidationError' อย่างชัดเจน นี่เป็นแนวทางปฏิบัติที่ดีเนื่องจากจะแทนที่ชื่อ 'Error' เริ่มต้นและระบุประเภทข้อผิดพลาดแบบกำหนดเองของเราอย่างชัดเจน
• บรรทัด Error.captureStackTrace(this, ValidationError) คือการเพิ่มประสิทธิภาพเฉพาะ V8 (พบบ่อยในสภาพแวดล้อม Node.js) ซึ่งช่วยในการจับภาพ stack trace ที่ถูกต้อง โดยไม่รวมการเรียก constructor เองออกจาก stack นี่เป็นทางเลือก แต่แนะนำเพื่อให้การแก้ไขข้อบกพร่องดีขึ้น

การโยนและดักจับข้อผิดพลาดแบบกำหนดเอง

ตอนนี้ มาดูกันว่าเราจะโยนและดักจับ ValidationError นี้ได้อย่างไร

            
function validateEmail(email: string): void {
  if (!email || !email.includes('@')) {
    throw new ValidationError('Invalid email format. Email must contain an "@" symbol.');
  }
  console.log('Email is valid.');
}

try {
  validateEmail('test@example.com');
  validateEmail('invalid-email');
} catch (error) {
  if (error instanceof ValidationError) {
    console.error(`Validation Error: ${error.message}`);
    // You can perform specific actions for validation errors here
  } else {
    // Handle other unexpected errors
    console.error(`An unexpected error occurred: ${error.message}`);
  }
}

            

              
                Copy
              
            
          

ในบล็อก catch เราใช้ instanceof ValidationError เพื่อระบุและจัดการข้อผิดพลาดแบบกำหนดเองของเราโดยเฉพาะ สิ่งนี้ช่วยให้มีตรรกะการจัดการข้อผิดพลาดที่แตกต่างกัน

การเพิ่มคุณสมบัติเฉพาะโดเมนลงในข้อผิดพลาดแบบกำหนดเอง

พลังที่แท้จริงของประเภทข้อผิดพลาดแบบกำหนดเองมาจากการที่สามารถพกพาข้อมูลเพิ่มเติมที่เฉพาะเจาะจงตามบริบทได้ มาสร้างข้อผิดพลาดที่ซับซ้อนยิ่งขึ้นสำหรับแอปพลิเคชันอีคอมเมิร์ซสมมติ เช่น InsufficientStockError

            
interface Product {
  id: string;
  name: string;
  stock: number;
}

class InsufficientStockError extends Error {
  public readonly productId: string;
  public readonly requestedQuantity: number;
  public readonly availableStock: number;

  constructor(product: Product, requestedQuantity: number) {
    const message = `Insufficient stock for product "${product.name}" (ID: ${product.id}). Requested: ${requestedQuantity}, Available: ${product.stock}.`;
    super(message);
    this.name = 'InsufficientStockError';

    this.productId = product.id;
    this.requestedQuantity = requestedQuantity;
    this.availableStock = product.stock;

    if (Error.captureStackTrace) {
      Error.captureStackTrace(this, InsufficientStockError);
    }
  }
}

// --- Usage Example ---

const productInStock: Product = {
  id: 'p123',
  name: 'Wireless Mouse',
  stock: 5
};

function placeOrder(product: Product, quantity: number): void {
  if (quantity > product.stock) {
    throw new InsufficientStockError(product, quantity);
  }
  console.log(`Order placed successfully for ${quantity} of ${product.name}.`);
  // ... update stock, process payment etc.
}

try {
  placeOrder(productInStock, 3);
  placeOrder(productInStock, 7); // This will throw InsufficientStockError
} catch (error) {
  if (error instanceof InsufficientStockError) {
    console.error(`Order failed: ${error.message}`);
    console.error(`Details - Product ID: ${error.productId}, Requested: ${error.requestedQuantity}, Available: ${error.availableStock}`);
    // Possible actions: Suggest alternative products, notify user, log for inventory management.
  } else {
    console.error(`An unexpected error occurred during order placement: ${error.message}`);
  }
}

            

              
                Copy
              
            
          

ในตัวอย่างนี้:

• InsufficientStockError มีคุณสมบัติเพิ่มเติม: productId, requestedQuantity และ availableStock
• คุณสมบัติเหล่านี้ถูกเริ่มต้นใน constructor และส่งพร้อมกับข้อผิดพลาด
• เมื่อจับข้อผิดพลาด เราสามารถเข้าถึงคุณสมบัติเหล่านี้เพื่อให้ข้อเสนอแนะโดยละเอียดเพิ่มเติม หรือกระตุ้นตรรกะการกู้คืนเฉพาะ สำหรับผู้ชมทั่วโลก ข้อมูลแบบละเอียดนี้มีความสำคัญอย่างยิ่งสำหรับทีมสนับสนุนหรือระบบอัตโนมัติในการทำความเข้าใจและแก้ไขปัญหาได้อย่างมีประสิทธิภาพในภูมิภาคต่างๆ

การจัดโครงสร้างลำดับชั้นข้อผิดพลาดแบบกำหนดเองของคุณ

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

พิจารณาสถานการณ์ที่คุณมีข้อผิดพลาดที่เกี่ยวข้องกับ API ประเภทต่างๆ:

            
// Base API Error
class ApiError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'ApiError';
    if (Error.captureStackTrace) {
      Error.captureStackTrace(this, ApiError);
    }
  }
}

// Specific API Errors inheriting from ApiError
class NetworkError extends ApiError {
  public readonly statusCode?: number;

  constructor(message: string, statusCode?: number) {
    super(message);
    this.name = 'NetworkError';
    this.statusCode = statusCode;
    if (Error.captureStackTrace) {
      Error.captureStackTrace(this, NetworkError);
    }
  }
}

class AuthenticationError extends ApiError {
  constructor(message: string = 'Authentication failed. Please check your credentials.') {
    super(message);
    this.name = 'AuthenticationError';
    if (Error.captureStackTrace) {
      Error.captureStackTrace(this, AuthenticationError);
    }
  }
}

class ResourceNotFoundError extends ApiError {
  public readonly resourceId: string;

  constructor(resourceId: string, message: string = `Resource with ID "${resourceId}" not found.`) {
    super(message);
    this.name = 'ResourceNotFoundError';
    this.resourceId = resourceId;
    if (Error.captureStackTrace) {
      Error.captureStackTrace(this, ResourceNotFoundError);
    }
  }
}

// --- Usage Example ---

async function fetchUserData(userId: string): Promise<any> {
  const response = await fetch(`/api/users/${userId}`);

  if (!response.ok) {
    if (response.status === 401) {
      throw new AuthenticationError();
    } else if (response.status === 404) {
      throw new ResourceNotFoundError(userId);
    } else {
      throw new NetworkError(`API request failed with status ${response.status}`, response.status);
    }
  }
  return response.json();
}

try {
  const user = await fetchUserData('user123');
  console.log('User data:', user);
} catch (error) {
  if (error instanceof AuthenticationError) {
    console.error('Authentication Error:', error.message);
    // Redirect to login page globally.
  } else if (error instanceof ResourceNotFoundError) {
    console.error('Resource Not Found:', error.message);
    // Inform user that the requested resource is unavailable.
  } else if (error instanceof NetworkError) {
    console.error(`Network Error: ${error.message} (Status: ${error.statusCode})`);
    // Potentially retry the request or inform the user about connection issues.
  } else {
    console.error('An unknown API error occurred:', error.message);
  }
}

            

              
                Copy
              
            
          

ในโครงสร้างลำดับชั้นนี้:

• ApiError ทำหน้าที่เป็นฐานร่วมกันสำหรับปัญหาที่เกี่ยวข้องกับ API ทั้งหมด
• NetworkError, AuthenticationError และ ResourceNotFoundError สืบทอดมาจาก ApiError ทำให้สามารถจัดการแต่ละประเภทได้อย่างเฉพาะเจาะจง
• บล็อก catch สามารถตรวจสอบข้อผิดพลาดที่เฉพาะเจาะจงที่สุดก่อน (เช่น AuthenticationError) แล้วกลับไปใช้ข้อผิดพลาดทั่วไปมากขึ้น (เช่น ApiError) หากจำเป็น สิ่งนี้มีความสำคัญอย่างยิ่งสำหรับแอปพลิเคชันระหว่างประเทศที่ภูมิภาคต่างๆ อาจมีความเสถียรของเครือข่ายหรือข้อกำหนดด้านกฎระเบียบที่แตกต่างกัน ซึ่งส่งผลต่อการรับรองความถูกต้อง

แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้งานประเภทข้อผิดพลาดแบบกำหนดเอง

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

1. ระบุให้ชัดเจน: ตั้งชื่อคลาสข้อผิดพลาดของคุณอย่างชัดเจนและอธิบายได้ ชื่อนั้นเองควรสื่อถึงลักษณะของข้อผิดพลาด
2. สืบทอดจาก Error: ขยายคลาส Error ในตัวเสมอเพื่อให้แน่ใจว่าข้อผิดพลาดแบบกำหนดเองของคุณทำงานเหมือนกับข้อผิดพลาด JavaScript มาตรฐาน และมีคุณสมบัติที่จำเป็น เช่น message และ stack
3. ตั้งค่าคุณสมบัติ name: ตั้งค่า this.name เป็นชื่อคลาสข้อผิดพลาดแบบกำหนดเองของคุณอย่างชัดเจน สิ่งนี้มีความสำคัญอย่างยิ่งสำหรับการระบุระหว่างรันไทม์
4. รวมข้อมูลที่เกี่ยวข้อง: เพิ่มคุณสมบัติลงในข้อผิดพลาดแบบกำหนดเองของคุณที่ให้บริบทและอำนวยความสะดวกในการแก้ไขข้อบกพร่องหรือการกู้คืน คิดเกี่ยวกับข้อมูลที่นักพัฒนาหรือระบบอัตโนมัติจะต้องเข้าใจและแก้ไขปัญหา
5. จัดทำเอกสารข้อผิดพลาดของคุณ: เช่นเดียวกับโค้ดของคุณ ประเภทข้อผิดพลาดแบบกำหนดเองของคุณควรได้รับการจัดทำเอกสาร อธิบายว่าแต่ละข้อผิดพลาดหมายถึงอะไร คุณสมบัติใดที่พกพา และเมื่อใดที่อาจเกิดขึ้น สิ่งนี้มีความสำคัญอย่างยิ่งสำหรับทีมที่กระจายอยู่ทั่วโลก
6. การโยนและการจับที่สอดคล้องกัน: สร้างแบบแผนภายในทีมของคุณเกี่ยวกับวิธีการและตำแหน่งที่จะโยนข้อผิดพลาด และวิธีการจับและจัดการข้อผิดพลาดเหล่านั้น ความสอดคล้องนี้เป็นกุญแจสำคัญสำหรับแนวทางที่เป็นหนึ่งเดียวในการจัดการข้อผิดพลาดในสภาพแวดล้อมแบบกระจาย
7. หลีกเลี่ยงการใช้งานมากเกินไป: แม้ว่าข้อผิดพลาดแบบกำหนดเองจะมีประสิทธิภาพ แต่อย่าสร้างข้อผิดพลาดสำหรับทุกความไม่สะดวกเล็กน้อย ใช้สำหรับเงื่อนไขข้อผิดพลาดที่แตกต่างกันซึ่งต้องมีการจัดการเฉพาะ หรือพกพาข้อมูลตามบริบทที่สำคัญ
8. พิจารณา Error Codes: สำหรับระบบที่ต้องการการระบุข้อผิดพลาดเชิงโปรแกรมในภาษาหรือแพลตฟอร์มที่แตกต่างกัน ให้พิจารณาเพิ่มรหัสข้อผิดพลาดที่เป็นตัวเลขหรือสตริงลงในประเภทข้อผิดพลาดแบบกำหนดเองของคุณ สิ่งนี้อาจเป็นประโยชน์สำหรับการแปลเป็นภาษาท้องถิ่นหรือการแมปข้อผิดพลาดไปยังบทความสนับสนุนเฉพาะ
9. การจัดการข้อผิดพลาดจากส่วนกลาง: ในแอปพลิเคชันขนาดใหญ่ ให้พิจารณาโมดูลหรือบริการการจัดการข้อผิดพลาดจากส่วนกลางที่สกัดกั้นและประมวลผลข้อผิดพลาด เพื่อให้มั่นใจถึงการบันทึก การรายงาน และศักยภาพแม้กระทั่งกลไกการตอบรับจากผู้ใช้ที่สอดคล้องกันในส่วนต่างๆ ของแอปพลิเคชัน นี่เป็นรูปแบบที่สำคัญสำหรับแอปพลิเคชันระดับโลก

ข้อควรพิจารณาทั่วโลกและการแปลเป็นภาษาท้องถิ่น

เมื่อพัฒนาสำหรับผู้ชมทั่วโลก ข้อความแสดงข้อผิดพลาดเอง (คุณสมบัติ message) จำเป็นต้องได้รับการพิจารณาอย่างรอบคอบ:

• หลีกเลี่ยงการแปลเป็นภาษาท้องถิ่นในสตริงข้อความแสดงข้อผิดพลาดโดยตรง: แทนที่จะฮาร์ดโค้ดข้อความที่แปลเป็นภาษาท้องถิ่นในคลาสข้อผิดพลาดของคุณ ให้ออกแบบระบบของคุณเพื่อดึงข้อความที่แปลเป็นภาษาท้องถิ่นตามภาษาของผู้ใช้หรือการตั้งค่าแอปพลิเคชัน ข้อผิดพลาดแบบกำหนดเองของคุณอาจพกพา errorCode หรือ key ที่บริการแปลเป็นภาษาท้องถิ่นสามารถใช้ได้
• เน้นที่ข้อความที่นักพัฒนาเผชิญ: ผู้ชมหลักสำหรับข้อความแสดงข้อผิดพลาดโดยละเอียดภายในออบเจ็กต์ข้อผิดพลาดเองมักจะเป็นนักพัฒนา ดังนั้น ตรวจสอบให้แน่ใจว่าข้อความเหล่านี้ชัดเจน กระชับ และถูกต้องทางเทคนิค ข้อความแสดงข้อผิดพลาดที่ผู้ใช้เผชิญควรได้รับการจัดการแยกกันและเป็นมิตรกับผู้ใช้และแปลเป็นภาษาท้องถิ่น
• ชุดอักขระสากล: ตรวจสอบให้แน่ใจว่าคุณสมบัติสตริงใดๆ ภายในข้อผิดพลาดแบบกำหนดเองของคุณสามารถจัดการชุดอักขระสากลได้อย่างถูกต้อง การจัดการสตริงมาตรฐานของ TypeScript และ JavaScript โดยทั่วไปรองรับ Unicode ได้ดี

ตัวอย่างเช่น ข้อผิดพลาดแบบกำหนดเองอาจมีลักษณะดังนี้:

            
class UserNotFoundError extends Error {
  public readonly userId: string;
  public readonly errorCode: string = 'ERR_USER_NOT_FOUND'; // For localization/lookup

  constructor(userId: string, message: string = 'User not found.') {
    super(message); // Default message, can be overridden or looked up.
    this.name = 'UserNotFoundError';
    this.userId = userId;
    if (Error.captureStackTrace) {
      Error.captureStackTrace(this, UserNotFoundError);
    }
  }
}

// In a localization service:
function getLocalizedErrorMessage(error: Error & { errorCode?: string }, locale: string): string {
  if (!error.errorCode) {
    return error.message;
  }

  const messages: { [key: string]: { [key: string]: string } } = {
    'en-US': {
      'ERR_USER_NOT_FOUND': `User with ID ${ (error as any).userId } could not be found.`
    },
    'es-ES': {
      'ERR_USER_NOT_FOUND': `No se encontró al usuario con ID ${ (error as any).userId }.`
    }
    // ... other locales
  };

  return messages[locale]?.[error.errorCode] || error.message;
}

// Usage:
try {
  // ... attempt to find user
  throw new UserNotFoundError('abc-123');
} catch (error) {
  if (error instanceof UserNotFoundError) {
    const userMessage = getLocalizedErrorMessage(error, 'es-ES');
    console.error(`Error: ${userMessage}`); // Displays Spanish message
  } else {
    console.error(`Generic error: ${error.message}`);
  }
}

            

              
                Copy
              
            
          

บทสรุป

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

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