ném Ngoại lệ vào các khối cuối cùng

Có một cách thanh lịch nào để xử lý các trường hợp ngoại lệ được đưa vào finallykhối không?

Ví dụ:

try {
  // Use the resource.
}
catch( Exception ex ) {
  // Problem with the resource.
}
finally {
   try{
     resource.close();
   }
   catch( Exception ex ) {
     // Could not close the resource?
   }
}

Làm thế nào để bạn tránh try/ catchtrong finallykhối?

Tôi thường làm như thế này:

try {
  // Use the resource.
} catch( Exception ex ) {
  // Problem with the resource.
} finally {
  // Put away the resource.
  closeQuietly( resource );
}

Ở những nơi khác:

protected void closeQuietly( Resource resource ) {
  try {
    if (resource != null) {
      resource.close();
    }
  } catch( Exception ex ) {
    log( "Exception during Resource.close()", ex );
  }
}

Tôi thường sử dụng một trong các closeQuietlyphương pháp trong org.apache.commons.io.IOUtils:

public static void closeQuietly(OutputStream output) {
    try {
        if (output != null) {
            output.close();
        }
    } catch (IOException ioe) {
        // ignore
    }
}

Nếu bạn đang sử dụng Java 7 và resourcecài đặt AutoClosable, bạn có thể làm điều này (sử dụng InputStream làm ví dụ):

try (InputStream resource = getInputStream()) {
  // Use the resource.
}
catch( Exception ex ) {
  // Problem with the resource.
}

Có thể là hơi quá, nhưng có thể hữu ích nếu bạn đang để các ngoại lệ bong bóng và bạn không thể ghi lại bất kỳ thứ gì từ bên trong phương thức của mình (ví dụ: vì đó là một thư viện và bạn muốn để mã gọi xử lý các ngoại lệ và ghi nhật ký):

Resource resource = null;
boolean isSuccess = false;
try {
    resource = Resource.create();
    resource.use();
    // Following line will only run if nothing above threw an exception.
    isSuccess = true;
} finally {
    if (resource != null) {
        if (isSuccess) {
            // let close throw the exception so it isn't swallowed.
            resource.close();
        } else {
            try {
                resource.close();
            } catch (ResourceException ignore) {
                // Just swallow this one because you don't want it 
                // to replace the one that came first (thrown above).
            }
        }
    }
}

CẬP NHẬT: Tôi đã xem xét vấn đề này nhiều hơn một chút và tìm thấy một bài đăng trên blog tuyệt vời từ một người có suy nghĩ rõ ràng về điều này hơn tôi: http://illegalargumentexception.blogspot.com/2008/10/java-how-not-to-make -mess-of-stream.html Anh ấy tiến thêm một bước nữa và kết hợp hai ngoại lệ thành một, điều này tôi có thể thấy hữu ích trong một số trường hợp.

Kể từ Java 7, bạn không còn cần phải đóng tài nguyên một cách rõ ràng trong một khối cuối cùng thay vào đó bạn có thể sử dụng cú pháp try -with-resources. Câu lệnh try-with-resources là câu lệnh try khai báo một hoặc nhiều tài nguyên. Tài nguyên là một đối tượng phải được đóng lại sau khi chương trình kết thúc với nó. Câu lệnh try-with-resources đảm bảo rằng mỗi tài nguyên được đóng ở cuối câu lệnh. Bất kỳ đối tượng nào triển khai java.lang.AutoClosable, bao gồm tất cả các đối tượng triển khai java.io.Closable, đều có thể được sử dụng làm tài nguyên.

Giả sử đoạn mã sau:

try( Connection con = null;
     Statement stmt = con.createStatement();
     Result rs= stmt.executeQuery(QUERY);)
{  
     count = rs.getInt(1);
}

Nếu có bất kỳ ngoại lệ nào xảy ra, phương thức đóng sẽ được gọi trên mỗi tài nguyên trong số ba tài nguyên này theo thứ tự ngược lại mà chúng được tạo. Nó có nghĩa là phương thức close sẽ được gọi đầu tiên cho ResultSetm, sau đó là Statement và cuối cùng cho đối tượng Connection.

Cũng cần biết rằng bất kỳ ngoại lệ nào xảy ra khi các phương thức đóng tự động được gọi đều bị loại bỏ. Các ngoại lệ bị loại bỏ này có thể được truy xuất bằng phương thức getsuppressed () được định nghĩa trong lớp Throwable .

Nguồn: https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

Bỏ qua các ngoại lệ xảy ra trong khối 'cuối cùng' nói chung là một ý tưởng tồi trừ khi người ta biết những ngoại lệ đó sẽ là gì và chúng sẽ đại diện cho điều kiện gì. Trong kiểu try/finallysử dụng thông thường , trykhối đặt mọi thứ vào trạng thái mà mã bên ngoài sẽ không mong đợi và finallykhối khôi phục trạng thái của những thứ đó về trạng thái mà mã bên ngoài mong đợi. Mã bên ngoài bắt được ngoại lệ thường sẽ mong đợi rằng, bất chấp ngoại lệ, mọi thứ đã được khôi phục vềnormaltiểu bang. Ví dụ: giả sử một số mã bắt đầu một giao dịch và sau đó cố gắng thêm hai bản ghi; khối "cuối cùng" thực hiện hoạt động "quay lại nếu không được cam kết". Người gọi có thể được chuẩn bị cho một ngoại lệ xảy ra trong quá trình thực hiện thao tác "thêm" thứ hai và có thể mong đợi rằng nếu nó bắt được một ngoại lệ như vậy, cơ sở dữ liệu sẽ ở trạng thái như trước khi một trong hai thao tác được thử. Tuy nhiên, nếu một ngoại lệ thứ hai xảy ra trong quá trình khôi phục, thì những điều tồi tệ có thể xảy ra nếu người gọi đưa ra bất kỳ giả định nào về trạng thái cơ sở dữ liệu. Lỗi khôi phục dữ liệu đại diện cho một cuộc khủng hoảng lớn - một cuộc khủng hoảng không nên bị bắt bởi mã chỉ mong đợi một ngoại lệ "Không thêm được bản ghi".

Khuynh hướng cá nhân của tôi là có một phương pháp cuối cùng bắt các ngoại lệ xảy ra và bọc chúng trong một "CleanupFailedException", nhận ra rằng lỗi đó đại diện cho một vấn đề lớn và một ngoại lệ như vậy không nên được coi nhẹ.

Một giải pháp, nếu hai Ngoại lệ là hai lớp khác nhau

try {
    ...
    }
catch(package1.Exception err)
   {
    ...
   }
catch(package2.Exception err)
   {
   ...
   }
finally
  {
  }

Nhưng đôi khi bạn không thể tránh được lần thử thứ hai này. ví dụ để đóng một luồng

InputStream in=null;
try
 {
 in= new FileInputStream("File.txt");
 (..)// do something that might throw an exception during the analysis of the file, e.g. a SQL error
 }
catch(SQLException err)
 {
 //handle exception
 }
finally
 {
 //at the end, we close the file
 if(in!=null) try { in.close();} catch(IOException err) { /* ignore */ }
 }

Tại sao bạn muốn tránh khối bổ sung? Vì khối cuối cùng chứa các hoạt động "bình thường" có thể tạo ra một ngoại lệ VÀ bạn muốn khối cuối cùng chạy hoàn toàn, bạn PHẢI bắt các ngoại lệ.

Nếu bạn không mong đợi khối cuối cùng sẽ đưa ra một ngoại lệ và bạn không biết cách xử lý ngoại lệ (bạn sẽ chỉ kết xuất dấu vết ngăn xếp), hãy để ngoại lệ bong bóng ngăn xếp lệnh gọi (xóa try-catch khỏi cuối cùng khối).

Nếu bạn muốn giảm việc nhập, bạn có thể triển khai khối try-catch bên ngoài "toàn cầu", khối này sẽ bắt tất cả các ngoại lệ được đưa vào các khối cuối cùng:

try {
    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }

    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }

    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }
} catch (Exception ex) {
    ...
}

Sau nhiều lần cân nhắc, tôi thấy mã sau là tốt nhất:

MyResource resource = null;
try {
    resource = new MyResource();
    resource.doSomethingFancy();
    resource.close(); 
    resource = null;  
} finally {
    closeQuietly(resource)
}

void closeQuietly(MyResource a) {
    if (a!=null)
        try {
             a.close();
        } catch (Exception e) {
             //ignore
        }
}

Mã đó đảm bảo sau:

1. Tài nguyên được giải phóng khi mã hoàn tất
2. Các ngoại lệ được ném ra khi đóng tài nguyên sẽ không bị tiêu thụ nếu không xử lý chúng.
3. Mã không cố gắng đóng tài nguyên hai lần, sẽ không có ngoại lệ không cần thiết nào được tạo.

Nếu có thể, bạn nên kiểm tra để tránh tình trạng lỗi bắt đầu.

try{...}
catch(NullArgumentException nae){...}
finally
{
  //or if resource had some useful function that tells you its open use that
  if (resource != null) 
  {
      resource.Close();
      resource = null;//just to be explicit about it was closed
  }
}

Ngoài ra, bạn có thể chỉ nên bắt các ngoại lệ mà bạn có thể khôi phục, nếu bạn không thể khôi phục thì hãy để nó phổ biến đến cấp cao nhất của chương trình của bạn. Nếu bạn không thể kiểm tra điều kiện lỗi, bạn sẽ phải bao quanh mã của mình bằng một khối thử bắt giống như bạn đã làm (mặc dù tôi khuyên bạn vẫn nên bắt các lỗi cụ thể, được mong đợi).

Bạn có thể cấu trúc lại cấu trúc này thành một phương thức khác ...

public void RealDoSuff()
{
   try
   { DoStuff(); }
   catch
   { // resource.close failed or something really weird is going on 
     // like an OutOfMemoryException 
   }
}

private void DoStuff() 
{
  try 
  {}
  catch
  {
  }
  finally 
  {
    if (resource != null) 
    {
      resource.close(); 
    }
  }
}

Tôi thường làm điều này:

MyResource r = null;
try { 
   // use resource
} finally {   
    if( r != null ) try { 
        r.close(); 
    } catch( ThatSpecificExceptionOnClose teoc ){}
}

Cơ sở lý luận: Nếu tôi đã làm xong tài nguyên và vấn đề duy nhất tôi gặp phải là đóng nó, thì tôi không thể làm được gì nhiều về nó. Sẽ không có ý nghĩa gì khi giết toàn bộ chuỗi nếu tôi đã hoàn tất với tài nguyên.

Đây là một trong những trường hợp ít nhất đối với tôi, có thể an toàn khi bỏ qua ngoại lệ đã kiểm tra đó.

Cho đến ngày nay, tôi không gặp vấn đề gì khi sử dụng thành ngữ này.

try {
    final Resource resource = acquire();
    try {
        use(resource);
    } finally {
        resource.release();
    }
} catch (ResourceException exx) {
    ... sensible code ...
}

Công việc hoàn thành. Không có bài kiểm tra nào. Bắt đơn, bao gồm các ngoại lệ thu được và phát hành. Tất nhiên bạn có thể sử dụng thành ngữ Execute Around và chỉ phải viết nó một lần cho mỗi loại tài nguyên.

Thay đổi Resourcetừ câu trả lời hay nhất thànhCloseable

Thực hiện các luồng CloseableDo đó bạn có thể sử dụng lại phương thức cho tất cả các luồng

protected void closeQuietly(Closeable resource) {
    if (resource == null) 
        return;
    try {
        resource.close();
    } catch (IOException e) {
        //log the exception
    }
}

Tôi đã gặp phải một tình huống tương tự trong đó tôi không thể sử dụng thử với tài nguyên nhưng tôi cũng muốn xử lý ngoại lệ đến từ khi đóng, không chỉ ghi nhật ký và bỏ qua nó như cơ chế closeQuietly. trong trường hợp của tôi, tôi không thực sự xử lý một luồng đầu ra, vì vậy lỗi khi đóng được quan tâm nhiều hơn là một luồng đơn giản.

IOException ioException = null;
try {
  outputStream.write("Something");
  outputStream.flush();
} catch (IOException e) {
  throw new ExportException("Unable to write to response stream", e);
}
finally {
  try {
    outputStream.close();
  } catch (IOException e) {
    ioException = e;
  }
}
if (ioException != null) {
  throw new ExportException("Unable to close outputstream", ioException);
}