Các loại ngoại lệ được sử dụng lại nên được ưa chuộng hơn các loại sử dụng một lần?

Hãy nói rằng tôi có Doors được quản lý bởi a DoorService. Các DoorServicechịu trách nhiệm về việc mở, đóng cửa và khóa cửa mà được lưu trữ trên cơ sở dữ liệu.

public interface DoorService
{
    void open(Door door) throws DoorLockedException, DoorAlreadyOpenedException;

    void close(Door door) throws DoorAlreadyClosedException;

    /**
     * Closes the door if open
     */
    void lock(Door door) throws DoorAlreadyLockedException;
}

Đối với phương pháp khóa, có một DoorAlreadyLockedExceptionvà cho phương pháp mở có một DoorLockedException. Đây là một tùy chọn nhưng có các tùy chọn khác có thể:

1) Sử dụng DoorLockedExceptioncho mọi thứ, hơi khó xử khi bắt ngoại lệ trong lock()cuộc gọi

try
{
    doorService.lock(myDoor);
}
catch(DoorLockedException ex) // door ALREADY locked
{
    //error handling...
}

2) Có 2 loại ngoại lệ DoorLockedExceptionvàDoorAlreadyLockedException

3) Có 2 loại ngoại lệ nhưng hãy để DoorAlreadyLockedException extends DoorLockedException

Đó là giải pháp tốt nhất và tại sao?

Tôi biết mọi người kiếm được nhiều tiền từ việc sử dụng ngoại lệ để kiểm soát dòng chảy nhưng đó không phải là vấn đề lớn nhất ở đây. Tôi thấy một vi phạm lệnh truy vấn tách lớn . Nhưng ngay cả đó không phải là tồi tệ nhất.

Không, điều tồi tệ nhất ở ngay đây:

/**
 * Closes the door if open
 */

Tại sao mọi thứ khác nổ tung nếu giả định của bạn về trạng thái cửa là sai nhưng lock()chỉ sửa nó cho bạn? Quên rằng điều này làm cho không thể khóa cửa mở, điều này là hoàn toàn có thể và đôi khi hữu ích. Không có vấn đề ở đây là bạn đã trộn lẫn hai triết lý khác nhau để xử lý các giả định không chính xác. Điều đó thật khó hiểu. Đừng làm vậy. Không cùng mức độ trừu tượng với cùng một kiểu đặt tên. Ow! Lấy một trong những ý tưởng bên ngoài. Các phương pháp dịch vụ cửa nên hoạt động theo cùng một cách.

Đối với vi phạm Phân tách truy vấn lệnh, tôi không cần phải cố gắng đóng cửa để tìm hiểu xem nó đóng hay mở. Tôi có thể chỉ cần hỏi. Dịch vụ cửa không cung cấp cách để làm điều đó mà không thể thay đổi trạng thái của cửa. Điều đó làm cho điều này trở nên tồi tệ hơn nhiều sau đó các lệnh cũng xảy ra để trả về các giá trị (một sự hiểu lầm phổ biến về những gì CQS nói về). Ở đây, các lệnh thay đổi trạng thái là cách duy nhất để thực hiện các truy vấn! Ow!

Đối với các trường hợp ngoại lệ đắt hơn mã trạng thái, đó là cuộc nói chuyện tối ưu hóa. Đủ nhanh là đủ nhanh. Không có vấn đề thực sự là con người không mong đợi ngoại lệ cho các trường hợp điển hình. Bạn có thể tranh luận về những gì điển hình tất cả những gì bạn thích. Đối với tôi câu hỏi lớn là làm thế nào bạn có thể đọc được mã bằng cách đọc.

ensureClosed(DoorService service, Door door){
  // Need door closed and unlocked. No idea of its state. What to do?
  try {
    service.open(door)
    service.close(door)
  } 
  catch( DoorLockedException e ){
    //Have no way to unlock the door so give up and die
    log(e);
    throw new NoOneGaveMeAKeyException(e);      
  }
  catch( DoorAlreadyOpenedException e ){
    try { 
      service.close(door);
    }
    catch( DoorAlreadyClosedException e ){
      //Some multithreaded goof has been messing with our door.
      //Oh well, this is what we wanted anyway.
      //Hope they didn't lock it.
    }
  }
}

Xin đừng bắt tôi viết mã như thế này. Xin vui lòng cho chúng tôi isLocked()và isClosed()phương pháp. Với những cái đó tôi có thể tự viết ensureClosed()và ensureUnlocked()phương pháp dễ đọc. Những người chỉ ném nếu điều kiện bài của họ bị vi phạm. Tôi chỉ muốn tìm thấy bạn đã viết và kiểm tra chúng tất nhiên. Chỉ cần không trộn chúng lại với những thứ ném khi chúng không thể thay đổi trạng thái. Ít nhất là cho họ phân biệt tên.

_{Dù bạn làm gì, xin đừng gọi bất cứ điều gì tryClose(). Đó là một cái tên khủng khiếp.}

Đối với DoorLockedExceptionmột mình và cũng có DoorAlreadyLockedExceptionbệnh nói điều này: tất cả là về việc sử dụng mã. Vui lòng không thiết kế các dịch vụ như thế này mà không viết mã bằng cách sử dụng và nhìn vào mớ hỗn độn bạn đang tạo. Tái cấu trúc và thiết kế lại cho đến khi sử dụng mã ít nhất có thể đọc được. Trong thực tế, xem xét việc viết mã bằng cách sử dụng đầu tiên.

ensureClosed(DoorService service, Door door){
  if( !service.isClosed(door) ){
    try{
      service.close(door);
    }
    catch( DoorAlreadyClosedException e ){
      //Some multithreaded goof has been messing with our door.
      //Oh well, this is what we wanted anyway.
      //Hope they didn't lock it.
    }
  } else {
    //This is what you wanted, so quietly do nothing. 
    //Why are you even here? Who bothers to write empty else conditions?
  }
}

ensureUnlocked(DoorService service, Door door){
  if( service.islocked(door) ){
    throw new NoOneGaveMeAKeyException(); 
  }
}

Phân biệt giữa DoorLockedExceptionvà DoorAlreadyLockedExceptiongợi ý rằng các loại ngoại lệ khác nhau đang được sử dụng để kiểm soát dòng chảy, một thực tế đã được coi là một phản mẫu.

Có nhiều loại ngoại lệ cho một cái gì đó lành tính này là vô cớ. Sự phức tạp bổ sung không vượt trội so với các lợi ích bổ sung.

Chỉ cần sử dụng DoorLockedExceptioncho tất cả mọi thứ.

Tốt hơn nữa, đơn giản là không làm gì cả. Nếu cửa đã bị khóa, thì nó vẫn sẽ ở trạng thái chính xác khi lock()phương thức hoàn thành. Đừng ném ngoại lệ cho các điều kiện không đáng kể.

Nếu bạn vẫn không thoải mái với điều đó, thì hãy đổi tên phương thức của bạn ensureDoorLocked().

Chủ đề của câu hỏi này "Các loại ngoại lệ tái chế có nên được ưa chuộng hơn các loại sử dụng một lần không?" dường như đã bị bỏ qua, không chỉ trong các câu trả lời, mà còn trong các chi tiết cho các câu hỏi (các câu trả lời là chi tiết của câu hỏi).

Tôi đồng ý với hầu hết những lời chỉ trích về mã mà người trả lời đã đưa ra.

Nhưng như một câu trả lời cho câu hỏi tiêu đề, tôi sẽ nói rằng bạn nên ưu tiên sử dụng lại 'ngoại lệ tái chế' hơn 'sử dụng một lần'.

Trong việc sử dụng xử lý ngoại lệ điển hình hơn, bạn có một DISTANCE tuyệt vời trong mã giữa nơi phát hiện và ném ngoại lệ, và nơi bắt ngoại lệ và xử lý ngoại lệ. Điều đó có nghĩa là sử dụng các loại riêng (mô-đun) trong xử lý ngoại lệ thường không hoạt động tốt. Một chương trình điển hình có xử lý ngoại lệ - sẽ có một số vị trí cấp cao nhất trong mã nơi xử lý ngoại lệ. Và vì đây là những vị trí cấp cao nhất, thật khó để họ có kiến ​​thức chi tiết về các khía cạnh hẹp của các mô-đun cụ thể.

Thay vào đó, họ có thể sẽ có một trình xử lý cấp cao cho một vài vấn đề cấp cao.

Lý do duy nhất sử dụng các lớp ngoại lệ tùy chỉnh chi tiết dường như có ý nghĩa trong mẫu của bạn, là bởi vì (và ở đây tôi đang nói xấu những người trả lời khác) - bạn không nên sử dụng xử lý ngoại lệ cho luồng điều khiển thông thường.

Một thay thế chưa được khám phá. Bạn có thể mô hình hóa điều sai với các lớp học của bạn, nếu bạn có những thứ này thay thế thì sao?

public interface OpenDoor
{
    public ClosedDoor close();
    public LockedDoor lock();
}

public interface ClosedDoor
{
    public OpenDoor open();
    public LockedDoor lock();
}

public interface LockedDoor
{
    // ? unlock? open?
}

Bây giờ không thể thử bất cứ điều gì là một lỗi. Bạn không cần bất kỳ ngoại lệ.

Tôi sẽ trả lời câu hỏi ban đầu, thay vì chỉ trích ví dụ.

Nói một cách đơn giản, nếu bạn mong đợi rằng khách hàng có thể cần phải phản ứng khác nhau cho từng trường hợp, thì nó đảm bảo một loại ngoại lệ mới.

Nếu bạn quyết định sử dụng nhiều loại ngoại lệ và tuy nhiên bạn hy vọng rằng máy khách có thể trong một số trường hợp muốn tạo một mệnh đề bắt chung cho chúng, có lẽ bạn nên tạo một siêu lớp trừu tượng mà cả hai đều mở rộng.

Đây là mã giả nhưng tôi nghĩ bạn sẽ hiểu ý tôi là:

public interface DoorService
{
    // ensures the door is open, uses key if locked, returns false if lock without a key or key does not fit
    bool Open(Door door, optional Key key) throws DoorStuckException, HouseOnFireException;

    // closes the door if open. already closed doors stay closed. Locked status does not change.
    void Close(Door door) throws throws DoorStuckException, HouseOnFireException;

    // closes the door if open and locks it
    void CloseAndLock(Door door, Key key) throws DoorStuckException, HouseOnFireException;
}

Có, tái sử dụng loại ngoại lệ có ý nghĩa, nếu bạn sử dụng ngoại lệ cho những điều thực sự đặc biệt . Bởi vì những điều thực sự đặc biệt chủ yếu là mối quan tâm xuyên suốt. Về cơ bản, bạn đang sử dụng Ngoại lệ cho các luồng điều khiển và điều đó dẫn đến những vấn đề đó.