आपका कोड बताता है कि आप इसका परिणाम उपयोग कर रहे हैं अतुल्यकालिक आपरेशन बाद में एक ही विधि में, आप CompletionException
से निपटने के लिए वैसे भी, इससे निपटने के लिए तो एक तरीका होगा ताकि,
public void myFunc() throws ServerException {
// Some code
CompletableFuture<A> a = CompletableFuture.supplyAsync(() -> {
try { return someObj.someFunc(); }
catch(ServerException ex) { throw new CompletionException(ex); }
});
// Some code running in parallel to someFunc()
A resultOfA;
try {
resultOfA = a.join();
}
catch(CompletionException ex) {
try {
throw ex.getCause();
}
catch(Error|RuntimeException|ServerException possible) {
throw possible;
}
catch(Throwable impossible) {
throw new AssertionError(impossible);
}
}
// some code using resultOfA
}
सभी अपवाद Supplier
की अतुल्यकालिक प्रसंस्करण के अंदर फेंक दिया एक में लपेटा हो जाएगी है CompletionException
join
पर कॉल करते समय, ServerException
को छोड़कर हम पहले ही CompletionException
में लपेट चुके हैं।
CompletionException
के कारण जब हम फिर से फेंक, हम अपवाद ServerException
जाँच की अनियंत्रित अपवाद हैं, Error
या RuntimeException
, या हमारे कस्टम अर्थात् उपवर्गों सामना कर सकते हैं। उपरोक्त कोड उन सभी को एक बहु-पकड़ के साथ संभालता है जो उन्हें फिर से फेंक देगा। चूंकि घोषित रिटर्न प्रकार getCause()
Throwable
है, इसलिए संकलक को हमें उस प्रकार को संभालने की आवश्यकता होती है, भले ही हम पहले से ही सभी संभावित प्रकारों को संभाले हैं। सीधा-आगे समाधान यह वास्तव में असंभव फेंकने को AssertionError
में लपेटना है।
वैकल्पिक रूप से, हम अपने कस्टम अपवाद के लिए एक वैकल्पिक परिणाम भविष्य इस्तेमाल कर सकते हैं:
public void myFunc() throws ServerException {
// Some code
CompletableFuture<ServerException> exception = new CompletableFuture<>();
CompletableFuture<A> a = CompletableFuture.supplyAsync(() -> {
try { return someObj.someFunc(); }
catch(ServerException ex) {
exception.complete(ex);
throw new CompletionException(ex);
}
});
// Some code running in parallel to someFunc()
A resultOfA;
try {
resultOfA = a.join();
}
catch(CompletionException ex) {
if(exception.isDone()) throw exception.join();
throw ex;
}
// some code using resultOfA
}
यह समाधान अपने मूल में उनके लिपटे रूप में सभी "अप्रत्याशित" throwables फिर से फेंक देते हैं, लेकिन केवल फेंक कस्टम ServerException
फॉर्म exception
भविष्य के माध्यम से पारित किया गया। ध्यान दें कि हमें यह सुनिश्चित करना होगा कि दौड़ की स्थिति से बचने के लिए exception
भविष्य से पूछने से पहले a
पूरा हो गया है (जैसे join()
पहले कॉल करना)।
के लिए धन्यवाद यह बहुत अच्छा है ... – Eugene
बहुत विस्तृत उत्तर। –