থ্রোয়েবলকে ধরা কি খারাপ অভ্যাস?

Question

এটা ধরা Throwableকি খারাপ অভ্যাস ?

উদাহরণস্বরূপ:

try {
    // Some code
} catch(Throwable e) {
    // handle the exception
}

এটি কি একটি খারাপ অভ্যাস বা আমাদের যথাসম্ভব নির্দিষ্ট হওয়া উচিত?

Comments

সম্পর্কিত: stackoverflow.com/questions/581878/... এবং stackoverflow.com/questions/2146108/...

— finnw

Answer 1

আপনার যথাসম্ভব সুনির্দিষ্ট হওয়া দরকার। অন্যথায় অপ্রত্যাশিত বাগগুলি এভাবেই সরে যেতে পারে।

এছাড়াও, Throwableকভারগুলি Errorপাশাপাশি এবং এটির কোনও ফিরতি নেই । আপনি এটি ধরতে / পরিচালনা করতে চান না, আপনি চান আপনার প্রোগ্রামটি অবিলম্বে মারা যেতে পারে যাতে আপনি এটি সঠিকভাবে ঠিক করতে পারেন।

Comments

এমন পরিস্থিতি রয়েছে যেখানে ধরা ত্রুটি এবং চালিয়ে যাওয়া উপযুক্ত। উদাহরণস্বরূপ: একটি সার্লেটে, যদি আপনি কোনও আউট অফ মেমরিরির সংযুক্ত করে কারণ একটি নির্দিষ্ট অনুরোধ সমস্ত মেমরি খায় তবে আপনি চালিয়ে যাওয়ার চেষ্টা করতে পারেন যেহেতু অনুরোধটি হ্যান্ডেল হওয়ার পরে অবজেক্টগুলি GC হবে। একই তদন্ত ত্রুটির জন্য যায়। আপনি কোনও অ্যাপ্লিকেশনটি শাটডাউন করবেন না কারণ একটি অনুরোধে কিছু ভুল হয়েছে।

— গাভি

কীভাবে বরাদ্দ করা হয়েছিল এবং ওমের আগে কী ছিল না তা আপনি কীভাবে জানবেন? টমক্যাট বা জবস এর মতো একটি জে 2 ই ই ধারকের ভিতরে পেয়ে গেলে সমস্ত বেট বন্ধ হয়ে যায়।

— বায়মাটার

আমাদের NoSuchMethodError হয়েছে এবং কৃতজ্ঞতার সাথে আমাদের সমস্ত গ্রাহকরা স্থাপনার দুই সপ্তাহ পরে সার্ভারটি বন্ধ করে দেয়নি out অর্থাত। আমাদের কাছে সর্বদা ক্যাচল থাকে থ্রোয়েবলকে ধরা এবং গ্রাহককে ত্রুটি পরিচালনা এবং প্রেরণের জন্য সর্বোত্তম প্রচেষ্টা করা। সর্বোপরি, প্রচুর পরিমাণে ত্রুটি পুনরুদ্ধারযোগ্য যে এটি কেবল 1000 টির মধ্যে 1 গ্রাহককে প্রভাবিত করতে পারে।

— ডিন হিলার

" আপনি চান যে আপনার প্রোগ্রামটি অবিলম্বে মারা যেতে পারে যাতে আপনি এটি সঠিকভাবে ঠিক করতে পারেন " => যদি আপনার প্রোগ্রামটি মারা যায় তবে কীভাবে ঘটেছিল আপনি কীভাবে জানবেন? সমস্যাটি লগ করতে থ্রোয়েবল / ত্রুটি ধরা একটি যুক্তিযুক্ত জিনিস ...

— Assylias

@Asslias একটি একা থাকা অ্যাপ্লিকেশন স্টাডারকে মারাত্মক ত্রুটি ছুঁড়ে দেবে।

— ফিলিপ হোয়াইটহাউস

Answer 2

এটি একটি খারাপ ধারণা। আসলে, এমনকি ধরা Exceptionসাধারণত একটি খারাপ ধারণা। আসুন একটি উদাহরণ বিবেচনা করুন:

try {
    inputNumber = NumberFormat.getInstance().formatNumber( getUserInput() );
} catch(Throwable e) {
    inputNumber = 10; //Default, user did not enter valid number
}

এখন, আসুন আমরা বলি যে getUserInput () কিছু সময়ের জন্য অবরুদ্ধ হয় এবং অন্য থ্রেডটি আপনার থ্রেডটিকে সবচেয়ে খারাপভাবে থামায় (এটি থ্রেড.স্টপ () বলে) আপনার ক্যাচ ব্লকে একটি ThreadDeathত্রুটি ধরা পড়বে । এটি অত্যন্ত খারাপ। ব্যতিক্রম ধরা পরে আপনার কোডের আচরণটি মূলত অপরিজ্ঞাত।

ব্যতিক্রম ধরার ক্ষেত্রেও একই রকম সমস্যা দেখা দেয়। হয়তো getUserInput()একটি InterruptException ব্যর্থ, অথবা ফলাফল, বা অন্যান্য ব্যর্থতা সমস্ত প্রকারের লগ ইন করার চেষ্টা করার সময় একটি অনুমতির ব্যতিক্রম অস্বীকার করেছেন। কী ভুল হয়েছে তা আপনার কোনও ধারণা নেই, কারণ এটির কারণে, সমস্যাটি কীভাবে ঠিক করবেন সে সম্পর্কেও আপনার কোনও ধারণা নেই।

আপনার কাছে আরও তিনটি ভাল বিকল্প রয়েছে:

1 - আপনি কীভাবে পরিচালনা করতে জানেন ঠিক তেমন ব্যতিক্রম (গুলি) ধরুন:

try {
    inputNumber = NumberFormat.getInstance().formatNumber( getUserInput() );
} catch(ParseException e) {
    inputNumber = 10; //Default, user did not enter valid number
}

2 - আপনি যে কোনও ব্যতিক্রম নিয়ে চলেছেন তা রিথ্রো এবং কীভাবে পরিচালনা করবেন তা জানেন না:

try {
    doSomethingMysterious();
} catch(Exception e) {
    log.error("Oh man, something bad and mysterious happened",e);
    throw e;
}

3 - একটি অবশেষে ব্লক ব্যবহার করুন যাতে আপনাকে পুনর্বিবেচনা করতে মনে রাখতে হবে না:

 Resources r = null;
 try {
      r = allocateSomeResources();
      doSomething(r);
 } finally {
     if(r!=null) cleanUpResources(r);
 }

Comments

এমনকি ব্যতিক্রম ধরাও ভাল নয় বলে উল্লেখ করার জন্য +1। কমপক্ষে একটি থ্রেডইন্টারটেড এক্সসেপশন রয়েছে যার জন্য বিশেষ যত্নের প্রয়োজন (সংক্ষেপে - এটি ধরার পরে, আপনাকে থ্রেডের

— বাধিত

আমি জানি এটি কেবল আপনার কথার উদাহরণ দেওয়ার জন্য তবে আমি মনে করি আপনার ব্যবহারকারী ইনপুটটি আলফানিউমারিক বা আপনার কোন বিন্যাসের প্রয়োজন এবং আপনি প্রতিবার সর্বত্র ক্যাচ ব্যবহার করার চেষ্টা করবেন না তবে আপনি একটি রেইগেক্স দিয়ে পরীক্ষা করতে পারেন।

— আমদেব

আমি ধরতে পারি না আমি যদি এটির না ধরি তবে কোনও ত্রুটি / থ্রোয়েবল আছে কিনা? লগগুলিতে আমি কিছুই দেখতে পেলাম না। জাভা ইই অ্যাপ্লিকেশন। আমি এই ক্যাচটি যোগ না করা পর্যন্ত সমস্যা কী তা না জেনে কিছু দিন আটকে গেল।

— ফিলিপ রেগো

আমি বিকল্পটি # 2টিকে খারাপ অনুশীলন হিসাবে বিবেচনা করি। লগ এবং পুনর্বিবেচনার সাথে 10 টি চেইন কলগুলি কল্পনা করুন। লগ ফাইলটি যদি দেখেন তবে আপনি খুশি হবেন না। ব্যতিক্রমটি 10 ​​বার লগ করা হয়েছে লগগুলি পড়ার জন্য খুব শক্ত করে। আইএমএইচও করা আরও ভাল throw new Exception("Some additional info, eg. userId " + userId, e);। এটি 10 ​​কারণে একটি দুর্দান্ত ব্যতিক্রম লগ ইন করা হবে।

— পেটর zjezdský

Answer 3

এছাড়াও সচেতন হন যে আপনি যখন ধরেন তখন আপনি Throwableএটিও ধরতে পারেন InterruptedExceptionযা একটি বিশেষ চিকিত্সার প্রয়োজন। আরও বিশদের জন্য বিঘ্নিত ধারণা নিয়ে কাজ করা দেখুন De

আপনি যদি কেবল চেক না করা ব্যতিক্রমগুলি ধরতে চান তবে আপনি এই প্যাটার্নটিও বিবেচনা করতে পারেন

try {
   ...
} catch (RuntimeException exception) {
  //do something
} catch (Error error) {
  //do something
}

এইভাবে, আপনি যখন নিজের কোডটি সংশোধন করবেন এবং এমন কোনও মেথড কল যুক্ত করুন যা একটি পরীক্ষিত ব্যতিক্রম ছুঁড়ে ফেলতে পারে, সংকলক আপনাকে সেটির কথা মনে করিয়ে দেবে এবং তারপরে আপনি এই ক্ষেত্রে কী করবেন তা সিদ্ধান্ত নিতে পারেন।

Answer 4

ত্রুটি শ্রেণীর জাভাদোক থেকে সরাসরি (যা এগুলি না ধরার পরামর্শ দেয়):

 * An <code>Error</code> is a subclass of <code>Throwable</code> 
 * that indicates serious problems that a reasonable application 
 * should not try to catch. Most such errors are abnormal conditions. 
 * The <code>ThreadDeath</code> error, though a "normal" condition,
 * is also a subclass of <code>Error</code> because most applications
 * should not try to catch it. 

 * A method is not required to declare in its <code>throws</code> 
 * clause any subclasses of <code>Error</code> that might be thrown 
 * during the execution of the method but not caught, since these 
 * errors are abnormal conditions that should never occur. 
 *
 * @author  Frank Yellin
 * @version %I%, %G%
 * @see     java.lang.ThreadDeath
 * @since   JDK1.0

Answer 5

এটি কোনও খারাপ অভ্যাস নয় যদি আপনার কোনও পদ্ধতি বাদে একেবারে ব্যতিক্রম বুদ্বুদ না পাওয়া যায়।

আপনি যদি সত্যিই ব্যতিক্রমটি পরিচালনা করতে না পারেন তবে এটি একটি খারাপ অভ্যাস। কেবল ধরা এবং পুনরায় নিক্ষেপ করা বা আরও খারাপ, পদ্ধতির স্বাক্ষরে "নিক্ষেপ" যুক্ত করা আরও ভাল, এটি রানটাইমএক্সেপশনে মুড়ে পুনরায় নিক্ষেপ করা।

Comments

সম্পূর্ণরূপে সম্মত হন - সমস্ত Throwableদৃষ্টান্ত পরিচালনা করার জন্য একেবারে বৈধ মামলা রয়েছে - যেমন কাস্টম ব্যতিক্রম লগিংয়ের জন্য।

— ইউরি নাকনটেকায়ি

Answer 6

থ্র্যাবেলে ক্যাচিং কখনও কখনও প্রয়োজনীয় হয় যদি আপনি লাইব্রেরি ব্যবহার করেন যা ত্রুটিগুলি বেশি উত্সাহের সাথে ফেলে দেয়, অন্যথায় আপনার গ্রন্থাগারটি আপনার অ্যাপ্লিকেশনটি মেরে ফেলতে পারে।

যাইহোক, এই পরিস্থিতিতে সমস্ত থ্রোবেবলের চেয়ে লাইব্রেরি দ্বারা ফেলে দেওয়া নির্দিষ্ট ত্রুটিগুলি নির্দিষ্ট করা ভাল।

Comments

বা আরও ভাল লিখিত গ্রন্থাগার ব্যবহার করবেন?

— রায়েডওয়াল্ড

আসলে, আপনার যদি পছন্দ ;-) থাকে

— ডিএনএ

থ্রোয়েবলগুলি ধরা এবং তাদের পুনরায় নিক্ষেপ করার ক্ষেত্রে সবচেয়ে বড় সমস্যাটি রয়েছে। এটি সত্যিই স্ট্যাকের সমস্ত পদ্ধতির জন্য একটি অসম্ভব ইন্টারফেস তৈরি করে। তারা হয় একটি নিক্ষেপযোগ্য মোকাবেলা করতে হবে বা একটি অপ্রয়োজনীয় ছোঁড়া নিক্ষেপযোগ্য স্বাক্ষর আছে যা অন্যদের মোকাবেলা করতে হবে।

— অ্যান্ড্রু নরম্যান

Answer 7

নিক্ষেপযোগ্য হ'ল সমস্ত শ্রেণীর জন্য নিক্ষেপযোগ্য (কেবল ব্যতিক্রম নয়) বর্গ শ্রেণি। আপনি যদি আউটআফমিউরিরির বা কার্নেল এরর ধরেন তবে খুব কমই আপনি করতে পারবেন ( কখন জাভা.এলং.এরর ধরবেন দেখুন ? )

ব্যতিক্রম ধরা যথেষ্ট হওয়া উচিত।

Answer 8

এটি আপনার যুক্তি নির্ভর করে বা আপনার অপশন / সম্ভাবনার সাথে আরও সুনির্দিষ্ট হতে পারে। যদি কোনও নির্দিষ্ট ব্যতিক্রম থাকে যা আপনি সম্ভবত অর্থবহ উপায়ে প্রতিক্রিয়া জানাতে পারেন তবে আপনি প্রথমে এটি ধরতে পারেন এবং এটি করতে পারেন।

যদি সেখানে না থাকে এবং আপনি অবশ্যই নিশ্চিত হন যে সমস্ত ব্যতিক্রম এবং ত্রুটিগুলির জন্য আপনি একই কাজ করবেন (উদাহরণস্বরূপ একটি ত্রুটি-বার্তা দিয়ে প্রস্থান করুন), তবে নিক্ষেপযোগ্যটিকে ধরতে সমস্যা হয় না।

সাধারণত প্রথম কেস হোল্ড হয় এবং আপনি ছুঁড়ে ফেলতে পারবেন না। তবে এখনও এটি প্রচুর ক্ষেত্রে রয়েছে যেখানে এটি ধরা ভাল কাজ করে।

Answer 9

যদিও এটি একটি খুব খারাপ অনুশীলন হিসাবে বর্ণনা করা হয়েছে, আপনি কখনও কখনও বিরল ক্ষেত্রে এটি খুঁজে পেতে পারেন যা এটি কেবল কার্যকর নয় তবে বাধ্যতামূলক। এখানে দুটি উদাহরণ দেওয়া হল।

এমন একটি ওয়েব অ্যাপ্লিকেশন যেখানে আপনাকে অবশ্যই ব্যবহারকারীর কাছে একটি অর্থ পূর্ণ ত্রুটি পৃষ্ঠা প্রদর্শন করতে হবে। এই কোডটি নিশ্চিত হয়ে নিন যে এটি try/catchআপনার সমস্ত অনুরোধ হ্যান্ডেলারের (সার্লেটস, স্ট্রুট ক্রিয়াকলাপ বা কোনও নিয়ামক ....) এর চারপাশে বড় is

try{
     //run the code which handles user request.
   }catch(Throwable ex){
   LOG.error("Exception was thrown: {}", ex);
     //redirect request to a error page. 
 }

}

অন্য উদাহরণ হিসাবে, বিবেচনা করুন আপনার একটি পরিষেবা শ্রেণি রয়েছে যা তহবিল স্থানান্তর ব্যবসায় পরিবেশন করে। এই পদ্ধতিটি TransferReceiptস্থানান্তর সম্পন্ন হলে বা NULLএটি না পারলে একটি প্রদান করে।

String FoundtransferService.doTransfer( fundtransferVO);

এখন ইমেজিং আপনি Listব্যবহারকারীর কাছ থেকে একাধিক তহবিল স্থানান্তর পাবেন এবং সেগুলি করতে আপনাকে অবশ্যই উপরের পরিষেবাটি ব্যবহার করতে হবে।

for(FundTransferVO fundTransferVO : fundTransferVOList){
   FoundtransferService.doTransfer( foundtransferVO);
}

তবে কোনও ব্যতিক্রম ঘটলে কী হবে? আপনার থামানো উচিত নয়, যেহেতু একটি স্থানান্তর সাফল্য পেয়েছে এবং অন্যটি হতে পারে না, আপনার সমস্ত ব্যবহারকারীর মাধ্যমে চালিয়ে যাওয়া উচিত Listএবং প্রতিটি স্থানান্তরকে ফলাফল প্রদর্শন করা উচিত। সুতরাং আপনি এই কোড দিয়ে শেষ।

for(FundTransferVO fundTransferVO : fundTransferVOList){
    FoundtransferService.doTransfer( foundtransferVO);
 }catch(Throwable ex){
    LOG.error("The transfer for {} failed due the error {}", foundtransferVO, ex);
  }
}

throwableসত্যিই ক্যাশেড এবং পরিচালনা করা হয়েছে তা দেখতে আপনি প্রচুর ওপেন সোর্স প্রকল্পগুলি ব্রাউজ করতে পারেন । উদাহরণস্বরূপ এখানে একটি অনুসন্ধান tomcat, struts2এবং primefaces:

https://github.com/apache/tomcat/search?utf8=%E2%9C%93&q=catch%28Trrowable https://github.com/apache/struts/search?utf8=%E2%9C%93&q=catch % 28 দ্রোণযোগ্য https://github.com/primefaces/primefaces/search?utf8=%E2%9C%93&q=catch%28Trrowable

Comments

এই লিঙ্কগুলিতে কোড দেখেছি। নিক্ষেপযোগ্য কেবল যে ধরা পড়ে না! থ্রোয়েবলের আগেও অন্যান্য ব্যতিক্রম ধরা পড়ে।

— বিকাশকারী

@ ডেভেলপার throwable

— ১০১

Answer 10

প্রশ্নটি কিছুটা অস্পষ্ট; আপনি জিজ্ঞাসা করছেন "এটি ধরা ঠিক কি Throwable", বা "কিছু ধরা Throwableএবং কিছু করা ঠিক নয়"? এখানে অনেক লোক উত্তরটির উত্তর দিয়েছিল, তবে এটি একটি পক্ষের বিষয়; সময় 99% না করা উচিত "গ্রাস" বা ব্যতিক্রম বাতিল হবে, আপনি আকর্ষণীয় হবে কিনা তা Throwableবা IOExceptionবা যাই হোক না কেন।

আপনি যদি ব্যতিক্রমটি প্রচার করেন তবে উত্তর (অনেক প্রশ্নের উত্তরের মতো) "এটি নির্ভর করে"। আপনি ব্যতিক্রম নিয়ে কী করছেন on আপনি কেন এটি ধরছেন তা নির্ভর করে।

আপনি কেন ধরতে চান তার একটি ভাল উদাহরণ Throwableহ'ল যদি কোনও ত্রুটি দেখা দেয় তবে কোনও ধরণের ক্লিনআপ সরবরাহ করা। উদাহরণস্বরূপ জেডিবিসি-তে, কোনও লেনদেনের সময় যদি কোনও ত্রুটি দেখা দেয় তবে আপনি লেনদেনটি আবার রোল করতে চান:

try {
  …
} catch(final Throwable throwable) {
  connection.rollback();
  throw throwable;
}

মনে রাখবেন যে ব্যতিক্রমটি বাতিল করা হয়নি, তবে প্রচারিত হয়েছে।

তবে একটি সাধারণ নীতি হিসাবে ধরা, Throwableকারণ আপনার কোনও কারণ নেই এবং কোন নির্দিষ্ট ব্যতিক্রমগুলি ছুঁড়ে দেওয়া হচ্ছে তা দেখতে খুব অলসতা হ'ল দুর্বল রূপ এবং একটি খারাপ ধারণা।

Answer 11

সাধারণভাবে বলতে গেলে আপনি এটি ধরা এড়াতে চান Errorতবে আমি (কমপক্ষে) দুটি সুনির্দিষ্ট ক্ষেত্রে যেখানে এটি করা উপযুক্ত তা ভাবতে পারি:

• আপনি ত্রুটির প্রতিক্রিয়া হিসাবে অ্যাপ্লিকেশনটি বন্ধ করতে চান, বিশেষত AssertionError যা অন্যথায় নিরীহ।
• আপনি কি এক্সিকিউটর সার্ভিস.সেম্বিট () এর অনুরূপ একটি থ্রেড-পুলিং মেকানিজম বাস্তবায়ন করছেন যা আপনাকে ব্যতিক্রমগুলি ব্যবহারকারীর কাছে ফেরত পাঠাতে হবে যাতে তারা এটি পরিচালনা করতে পারে।

Answer 12

যদি আমরা ব্যবহার নিক্ষেপযোগ্য , তাহলে এটি জুড়ে ত্রুটি পাশাপাশি এবং যে এটি।

উদাহরণ।

    public class ExceptionTest {
/**
 * @param args
 */
public static void m1() {
    int i = 10;
    int j = 0;
    try {
        int k = i / j;
        System.out.println(k);
    } catch (Throwable th) {
        th.printStackTrace();
    }
}

public static void main(String[] args) {
    m1();
}

}

আউটপুট:

java.lang.ArithmeticException: / by zero
at com.infy.test.ExceptionTest.m1(ExceptionTest.java:12)
at com.infy.test.ExceptionTest.main(ExceptionTest.java:25)

Answer 13

থ্রোয়েবল হ'ল সমস্ত ত্রুটি এবং অতিক্রমের সুপারক্লাস। আপনি যদি ক্যাচ ক্লজে থ্রোয়েবল ব্যবহার করেন তবে এটি কেবল সমস্ত ব্যতিক্রমই ধরা দেবে না, এটি সমস্ত ত্রুটিও ধরবে। ত্রুটিগুলি JVM দ্বারা মারাত্মক সমস্যাগুলি ইঙ্গিত করার জন্য নিক্ষেপ করা হয় যা কোনও অ্যাপ্লিকেশন দ্বারা পরিচালিত করার উদ্দেশ্যে নয়। এর জন্য সাধারণ উদাহরণগুলি হ'ল আউটআফমিউরিওর বা স্ট্যাকওভারফ্লো এরির। উভয়ই এমন পরিস্থিতির কারণে হয় যা অ্যাপ্লিকেশনের নিয়ন্ত্রণের বাইরে থাকে এবং পরিচালনা করা যায় না। সুতরাং আপনার থ্রোবেবলগুলি ধরা উচিত নয় যতক্ষণ না আপনার দৃ pretty় আত্মবিশ্বাস হয় যে এটি কেবল থ্রোয়েবলের অভ্যন্তরেই ব্যতিক্রম।

Answer 14

থ্রোয়েবলকে ধরার পক্ষে এটি সাধারণত খারাপ অভ্যাস হলেও (এই প্রশ্নটির অসংখ্য উত্তর দ্বারা বর্ণিত হিসাবে), যেখানে ধরা Throwableকার্যকর হয় সে দৃশ্যগুলি বেশ সাধারণ common সরলকরণের উদাহরণ সহ আমি আমার কাজের সময়ে ব্যবহার করি এমন একটি মামলার ব্যাখ্যা করি।

এমন একটি পদ্ধতি বিবেচনা করুন যা দুটি সংখ্যার সংযোজন সম্পাদন করে এবং সফল সংযোজনের পরে এটি নির্দিষ্ট লোকেদের জন্য একটি ইমেল সতর্কতা প্রেরণ করে। ধরে নিন যে প্রত্যাবর্তিত নম্বরটি গুরুত্বপূর্ণ এবং কলিং পদ্ধতি দ্বারা ব্যবহৃত।

public Integer addNumbers(Integer a, Integer b) {
    Integer c = a + b;          //This will throw a NullPointerException if either 
                                //a or b are set to a null value by the
                                //calling method
    successfulAdditionAlert(c);
    return c;
}

private void successfulAdditionAlert(Integer c) {
    try {
        //Code here to read configurations and send email alerts.
    } catch (Throwable e) {
        //Code to log any exception that occurs during email dispatch
    }
}

ইমেল সতর্কতা প্রেরণের কোডটি প্রচুর সিস্টেম কনফিগারেশন পড়ে এবং তাই কোডের সেই ব্লক থেকে নানারকম ব্যতিক্রম হতে পারে। আমরা কলার পদ্ধতিতে প্রচার করার জন্য সতর্কতা প্রেরণের সময় কোনও ব্যতিক্রমের মুখোমুখি হতে চাই না, কারণ সেই পদ্ধতিটি এটি সরবরাহ করে এমন দুটি পূর্ণসংখ্যার মানগুলির যোগফলের সাথে সম্পর্কিত। সুতরাং, ইমেল সতর্কতা প্রেরণের কোডটি একটি try-catchব্লকে স্থাপন করা হয় , যেখানে Throwableধরা পড়ে এবং কোনও ব্যতিক্রম কেবল লগ হয়, যাতে বাকী প্রবাহ অব্যাহত রাখে।

Comments

আমি চেষ্টা করব এবং ইমেল প্রেরণের কাজের (একটি সারি সহ) উত্সর্গীকৃত থ্রেড রেখে এড়াতে চাই।

— বুম্ব ২

আমি পরামর্শ দিচ্ছি যে এটি এখনও খারাপ কোড। Exceptionসমস্ত উপায়ে এস ধরুন , তবে তা নয় Throwable।

— অ্যান্ড্রুফ