জাভাতে চেক করা বনাম চেক করা ব্যতিক্রমগুলি বোঝা


703

" কার্যকর জাভা " -তে জোশুয়া ব্লচ বলেছিলেন

প্রোগ্রামিং ত্রুটির জন্য পুনরুদ্ধারযোগ্য শর্ত এবং রানটাইম ব্যতিক্রমগুলির জন্য চেক করা ব্যতিক্রমগুলি ব্যবহার করুন (দ্বিতীয় সংস্করণে আইটেম 58)

আমি এটি সঠিকভাবে বুঝতে পারি কিনা তা দেখুন।

এখানে পরীক্ষিত ব্যতিক্রম সম্পর্কে আমার বোঝার জন্য:

try{
    String userInput = //read in user input
    Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
    id = 0; //recover the situation by setting the id to 0
}

১. উপরেরটি কি চেক করা ব্যতিক্রম বলে বিবেচিত হয়?

২. রানটাইম এক্সেকশন কি চেক না করা ব্যতিক্রম?

এখানে একটি চেক করা ব্যতিক্রম সম্পর্কে আমার বোঝার বিষয়:

try{
    File file = new File("my/file/path");
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){

//3. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

৪. এখন, উপরের কোডটিও কি চেক করা ব্যতিক্রম হতে পারে? আমি কি পরিস্থিতি এভাবে পুনরুদ্ধার করতে পারি? আমি কি পারি? (দ্রষ্টব্য: আমার তৃতীয় প্রশ্ন catchউপরের ভিতরে রয়েছে)

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

৫. লোকেরা কেন এটি করে?

public void someMethod throws Exception{

}

কেন তারা ব্যতিক্রম বুদ্বুদ আপ করতে দেয়? ত্রুটিটি পরিচালনা করা কি আরও ভাল হয় না? কেন বুদবুদ?

I. ব্যতিক্রমটি ব্যবহার করে কি আমার সঠিক ব্যতিক্রমটি উত্সাহিত করা উচিত?

নীচে আমার পড়া আছে

জাভাতে, কখন আমার একটি চেক করা ব্যতিক্রম তৈরি করা উচিত এবং কখন এটি রানটাইম ব্যতিক্রম হওয়া উচিত?

চেক করা এবং চেক করা ব্যতিক্রমগুলি কখন চয়ন করবেন


6
আমার একটি চেক না করা ব্যতিক্রমের দুর্দান্ত উদাহরণ রয়েছে। আমার কাছে একটি DataSeriesশ্রেণি রয়েছে যা ডেটা ধারণ করে যা সর্বদা সময় ভিত্তিক ক্রমে থাকতে হবে। এ DataPointএর শেষে একটি নতুন যুক্ত করার পদ্ধতি রয়েছে DataSeries। আমার সমস্ত কোড যদি পুরো প্রকল্প জুড়ে সঠিকভাবে কাজ করে থাকে তবে কোনওটি DataPointশেষের সাথে যুক্ত করা উচিত নয় যা ইতিমধ্যে শেষের একটিতে পূর্বের তারিখ রয়েছে। পুরো প্রকল্পের প্রতিটি মডিউল এই সত্যবাদ দিয়ে নির্মিত। তবে, আমি এই শর্তটি পরীক্ষা করে দেখি এবং যদি এটি ঘটে থাকে তবে একটি চেক না করা ব্যতিক্রম ছুঁড়ে ফেলি। কেন? যদি এটি হয়, আমি কে এটি করছে তা জানতে এবং এটি ঠিক করতে চাই।
এরিক রবার্টসন

3
আরও বিভ্রান্তি যোগ করতে। 10 বছর আগে অনেক লোক চেক করা ব্যাতিক্রমের পক্ষে ছিলেন, তবে আজকালকার দৃষ্টিভঙ্গি "পরীক্ষিত ব্যতিক্রমগুলি খারাপ" এর দিকে আরও বেশি অগ্রসর হচ্ছে। (তবে আমি তাতে একমত নই)
কাজ

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

40
আমাদের চেক / চেক না করা ব্যতিক্রমগুলির বিস্তৃত বিভ্রান্তিকর শর্তাদি ব্যবহার করা উচিত stop এগুলিকে চেক-ম্যান্ডেটেড বনাম চেক-নন-বাধ্যতামূলক ব্যতিক্রম বলা উচিত ।
ধন্য গীকের

3
আমিও ভাবলাম যে আপনার পাঁচম পয়েন্টের সার্বজনীন শূন্য পদ্ধতিতে_ নাম ব্যতিক্রম ছোঁড়া {some কিছু লোক কেন তা করে?
মাভেň ツ

উত্তর:


474

অনেকে বলে থাকেন যে চেক করা ব্যতিক্রমগুলি (যেমন এগুলি আপনাকে স্পষ্টভাবে ধরা বা পুনর্বিবেচনা করা উচিত) ব্যবহার করা উচিত নয়। উদাহরণস্বরূপ এগুলিকে সি # তে মুছে ফেলা হয়েছে এবং বেশিরভাগ ভাষায় সেগুলি নেই। সুতরাং আপনি সর্বদা একটি সাবক্লাস নিক্ষেপ করতে পারেন RuntimeException(চেক না করা ব্যতিক্রম)

তবে, আমি মনে করি চেক করা ব্যতিক্রমগুলি কার্যকর - আপনি যখন আপনার API এর ব্যবহারকারীকে কীভাবে ব্যতিক্রমী পরিস্থিতি পরিচালনা করতে চান তা বাধ্য করতে চাইলে (যদি এটি পুনরুদ্ধারযোগ্য হয়) তখন সেগুলি ব্যবহৃত হয়। এটি জাভা প্ল্যাটফর্মে চেক করা ব্যতিক্রমগুলি অতিরিক্ত ব্যবহার করা হয়েছে যা লোকেরা তাদের ঘৃণা করে।

বিষয়টিতে আমার বর্ধিত দর্শন এখানে

বিশেষ প্রশ্ন হিসাবে:

  1. NumberFormatExceptionবিবেচনা কি চেক করা ব্যতিক্রম?
    নম্বরটি চেক NumberFormatExceptionকরা নেই (= এটির উপক্লাস RuntimeException)। কেন? আমি জানি না। (তবে একটি পদ্ধতি থাকা উচিত ছিল isValidInteger(..))

  2. কি RuntimeExceptionএকটি অবারিত ব্যতিক্রম?
    হ্যাঁ অবশ্যই.

  3. আমার এখানে কি করা উচিত?
    এটি এই কোডটি কোথায় এবং আপনি কী হতে চান তার উপর নির্ভর করে। যদি এটি ইউআই স্তর থাকে - এটি ধরুন এবং একটি সতর্কতা দেখান; যদি এটি পরিষেবা স্তরে থাকে - একেবারেই ধরবেন না - এটি বুদবুদ হতে দিন। শুধু ব্যতিক্রম গ্রাস করবেন না। বেশিরভাগ ক্ষেত্রে যদি ব্যতিক্রম ঘটে থাকে তবে আপনার মধ্যে একটি বেছে নেওয়া উচিত:

    • এটি লগ এবং ফিরে
    • এটিকে পুনর্বিবেচনা করুন (পদ্ধতি দ্বারা এটি নিক্ষেপ করার ঘোষণা করুন)
    • কনস্ট্রাক্টরে কারেন্টটি পাস করে একটি নতুন ব্যতিক্রম নির্মাণ করুন
  4. এখন, উপরের কোডটিও কি চেক করা ব্যতিক্রম হতে পারে? আমি কি পরিস্থিতি এভাবে পুনরুদ্ধার করতে পারি? আমি কি পারি?
    এটা হতে পারে। তবে কিছুই আপনাকে চেক না করা ব্যতিক্রমগুলি ধরতে বাধা দেয়

  5. লোকেরা Exceptionথ্রো ক্লজে ক্লাস যুক্ত করবে কেন ?
    বেশিরভাগ ক্ষেত্রে লোকেরা কী ধরবে এবং কী পুনর্বিবেচনা করবে তা বিবেচনা করতে অলস হয়। নিক্ষেপ Exceptionকরা একটি খারাপ অভ্যাস এবং এড়ানো উচিত।

হায় আফসোস, কখন ধরা হবে, কখন পুনর্নির্মাণ করবেন, কখন চেক ব্যবহার করবেন এবং কখন চেক করা ব্যতিক্রম ব্যবহার করবেন তা নির্ধারণ করার একক নিয়ম নেই। আমি সম্মত হ'ল এটি অনেক বিভ্রান্তি এবং প্রচুর খারাপ কোডের কারণ। সাধারণ নীতিটি ব্লচ দ্বারা বর্ণিত হয় (আপনি এর একটি অংশ উদ্ধৃত করেছেন)। এবং সাধারণ নীতিটি হ'ল স্তরটিকে ব্যতিক্রম করতে হবে যেখানে আপনি এটি পরিচালনা করতে পারেন th


36
ব্যতিক্রম ছোঁড়া সম্পর্কে, এটি সর্বদা নয় কারণ মানুষ অলস হয়, এটিও সাধারণ যে আপনি যখন ফ্রেমওয়ার্কগুলি প্রয়োগ করেন তখন কাঠামোর ব্যবহারকারীরা কোনও ব্যতিক্রম ছুঁড়ে ফেলতে সক্ষম হন। আপনি উদাহরণস্বরূপ জেএসইতে কলযোগ্য ইন্টারফেসের স্বাক্ষরটি পরীক্ষা করতে পারেন
Kaj

10
@ কাজ - হ্যাঁ, কলযোগ্য, ইন্টারসেপ্টর এবং পছন্দগুলি এর মতো সাধারণ জিনিসগুলি বিশেষ ক্ষেত্রে। তবে বেশিরভাগ ক্ষেত্রে এটি কারণ লোক অলস :)
বোজহো

7
পুনরায়: 3.1 "এটি লগইন করুন এবং প্রত্যাবর্তন করুন" ন্যায়বিচারের সাথে করুন Do এটি খাওয়া বা লুকিয়ে থাকা এবং ব্যতিক্রমের খুব কাছে। আমি এটি এমন কোনও কিছুর জন্য করব যা কোনও সমস্যা নির্দেশ করে না, এটি সত্যিই ব্যতিক্রমী নয়। লগগুলি খুব সহজেই প্লাবিত হয় এবং উপেক্ষা করা হয়।
ক্রিস

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

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

233

কোনও কিছু "পরীক্ষিত ব্যতিক্রম" কিনা তা আপনি ধরেন বা ক্যাচ ব্লকে আপনি যা করেন তার সাথে কিছুই করার নেই। এটি ব্যতিক্রম শ্রেণীর সম্পত্তি। যেকোনো কিছু একটি উপশ্রেণী যে Exception ব্যতীত জন্য RuntimeExceptionএবং তার উপশ্রেণী একটি চেক করা এর ব্যতিক্রম নয়।

জাভা সংকলক আপনাকে চেক করা ব্যতিক্রমগুলি ধরতে বা পদ্ধতি স্বাক্ষরে এগুলি ঘোষণা করতে বাধ্য করে। এটি প্রোগ্রামের সুরক্ষা উন্নত করার কথা ছিল, তবে সংখ্যাগরিষ্ঠ মতামত মনে হয় এটি তৈরির নকশা সমস্যাগুলির পক্ষে এটি উপযুক্ত নয়।

কেন তারা ব্যতিক্রম বুদ্বুদ আপ করতে দেয়? তাত্ক্ষণিকভাবে হ্যান্ডেল ত্রুটি আরও ভাল হয়? কেন বুদবুদ?

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


3
ধন্যবাদ! নীতিমালায় নষ্ট হয়ে যাওয়ার নীতিমালার কারণে আমি মাঝেমধ্যে ব্যতিক্রমগুলি আমার পদ্ধতিগুলির বাইরে ফেলে দিই। আমি আমার দলের বিকাশকারীদের মধ্যে একটি ব্যতিক্রমটি মোকাবেলা করার জন্য এটি তাদের অবধি একটি অবৈধ এক্সপাথ এক্সপ্রেশন লিখতে চাই। সম্ভাব্য ঘটনাগুলিতে তারা একটি ব্যতিক্রম ধরা পড়ে এবং কোড পর্যালোচনায় তারা এটি সম্পর্কে কিছুই শুনতে পাবে না।
jeremyjjbrown

12
"রানটাইম এক্সেকসেপশন এবং এর সাবক্লাস বাদে থ্রোয়েবলের যে কোনও সাবক্লাস যা চেক করা ব্যতিক্রম" " - আপনার বিবৃতিটি ভুল। ত্রুটিও থ্রোয়েবলের উত্তরাধিকার সূত্রে প্রাপ্ত এবং এটি চেক করা হয় না।
বার্টজিলা

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

2
"তবে বেশিরভাগের মতামত মনে হয় যে এটি তৈরির নকশা সমস্যাগুলির পক্ষে এটি উপযুক্ত নয়" " - অনুগ্রহ করে দয়া করে?
কেভেরিন

3
@ বার্টজিলা হ্যাঁ সম্পূর্ণতার জন্য, যেমন জাভাদোক Throwableবলেছেন: "থ্রোয়েবল এবং থ্রোয়েবলের যে কোনও সাবক্লাস যা রানটাইম এক্সেকশন বা ত্রুটির কোনও একটি সাবক্লাস নয় যাচাই করা ব্যতিক্রম হিসাবে বিবেচিত হয়"
বার্ট ভ্যান হিউকেলোম

74
  1. উপরেরটি কি চেক করা ব্যতিক্রম হিসাবে বিবেচিত? না আপনি যে ব্যতিক্রমটি পরিচালনা করছেন তা এটি Checked Exceptionযদি এটি হয় তবে তা তৈরি করে না RuntimeException

  2. কি RuntimeExceptionএকটি unchecked exception? হ্যাঁ

Checked Exceptionsহয় subclassesএর java.lang.Exception Unchecked Exceptionsদ্বারা subclassesএরjava.lang.RuntimeException

চেক করা ব্যতিক্রম ছোঁড়া কলগুলি চেষ্টা করার চেষ্টা করে of} ব্লক দিয়ে আবদ্ধ করা বা পদ্ধতির কলারে উপরের স্তরে পরিচালনা করা দরকার। সেক্ষেত্রে বর্তমান পদ্ধতিটি অবশ্যই ঘোষণা করবে যে এটি ব্যতিক্রমগুলি ছুঁড়েছে যাতে কলাররা ব্যতিক্রমটি পরিচালনা করার জন্য উপযুক্ত ব্যবস্থা করতে পারে।

আশাকরি এটা সাহায্য করবে.

প্রশ্ন: আমি কি সঠিক ব্যতিক্রমটি বুদবুদ করব বা ব্যতিক্রম ব্যবহার করে এটি মাস্ক করা উচিত?

উত্তর: হ্যাঁ এটি একটি খুব ভাল প্রশ্ন এবং গুরুত্বপূর্ণ নকশা বিবেচনা। ক্লাস ব্যতিক্রম একটি খুব সাধারণ ব্যতিক্রম শ্রেণি এবং অভ্যন্তরীণ নিম্ন স্তরের ব্যতিক্রম মোড়ানোর জন্য ব্যবহার করা যেতে পারে। আপনি আরও ভালভাবে একটি কাস্টম ব্যতিক্রম তৈরি করতে এবং এর ভিতরে মোড়ানো করতে পারেন। তবে, এবং একটি বড়টি - মূল মূল কারণটি কখনই অস্পষ্ট করে না। প্রাক্তন হিসাবে, Don't everঅনুসরণ করুন -

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

পরিবর্তে নিম্নলিখিতগুলি করুন:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

আসল মূল কারণের মৃতদেহগুলি খেয়ে ফেলা পুনরুদ্ধারের বাইরেও আসল কারণ হ'ল উত্পাদন সহায়তা দলগুলির জন্য দুঃস্বপ্ন যেখানে এগুলিতে সমস্ত কিছু অ্যাক্সেস দেওয়া হয় তা হ'ল অ্যাপ্লিকেশন লগ এবং ত্রুটি বার্তা। যদিও আধুনিক আধুনিক নকশা তবে অনেকে এটি প্রায়শই ব্যবহার করেন না কারণ বিকাশকারীরা কেবল কলারের কাছে অন্তর্নিহিত বার্তাটি দিতে ব্যর্থ হন। সুতরাং একটি দৃ note় নোট করুন: Always pass on the actual exceptionকোনও অ্যাপ্লিকেশন নির্দিষ্ট ব্যতিক্রম মোড়ানো বা না ফিরে।

চেষ্টা করার সময় RuntimeExceptions

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

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

এটি একটি খারাপ প্রোগ্রামিং অনুশীলন। পরিবর্তে একটি নাল চেক করা উচিত ছিল -

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

তবে এমন সময় আছে যখন এই জাতীয় ত্রুটি পরীক্ষা করা যেমন সংখ্যা বিন্যাসের মতো ব্যয়বহুল হয়, এটিকে বিবেচনা করুন -

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

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

সুতরাং NullPointerExceptionএবং NumberFormatExceptionউভয়ই RuntimeExceptionsহ'ল ত্রুটিযুক্ত প্রবণ কোডটির সম্ভাব্য ভূমিকা এড়াতে NullPointerExceptionআমি একটি NumberFormatExceptionস্পষ্টভাবে ধরার পরামর্শ দেওয়ার সময় একটি ক্যাপচারিংকে একটি গ্রেফুল নাল-চেক দিয়ে প্রতিস্থাপন করা উচিত ।


ধন্যবাদ. আপনি যখন বুদবুদ করছেন তখন আরও একটি প্রশ্ন exception, আমি কি সঠিক ব্যতিক্রমটি বুদবুদ করব বা এটি ব্যবহার করে মুখোশটি আটকানো উচিত Exception। আমি কিছু লিগ্যাসি কোডের উপরে কোড লিখছি Exceptionএবং সমস্ত জায়গাতেই বুদবুদ হয়ে যাচ্ছি । আমি ভাবছি এটাই যদি সঠিক আচরণ হয়?
থাং ফাম 21

1
এটি একটি খুব ভাল এবং গুরুত্বপূর্ণ প্রশ্ন, ব্যাখ্যাটি অন্তর্ভুক্ত করার জন্য আমার উত্তর সম্পাদনা করেছে।
d- লাইভ

আপনাকে অনেক ধন্যবাদ. আপনার পক্ষে কি আমাকে সামগ্রীটি প্রদর্শন করা সম্ভব হবে LoginFailureException(sqle)?
থাং ফাম

1
আমার কাছে এই স্টাফটির জন্য কোনও কোড নেই, আমি কেবল নামগুলি রান্না করেছি If আপনি যদি java.lang.Exception দেখতে পান তবে এর মধ্যে ৪ জন কনস্ট্রাক্টর রয়েছে যার মধ্যে দুটি java.lang.Trorowable গ্রহণ করে। উপরের স্নিপেটগুলিতে আমি ধরে নিয়েছি এবং একটি LoginFailureExceptionনির্মাতার Exceptionঘোষনা করেছিpublic LoginFailureException(Throwable cause) { super(cause) }
d-live

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

19

ঘ। আপনি যদি কোনও ব্যতিক্রম সম্পর্কে অনিশ্চিত থাকেন তবে, API টি দেখুন:

 java.lang.Object
 extended by java.lang.Throwable
  extended by java.lang.Exception
   extended by java.lang.RuntimeException  //<-NumberFormatException is a RuntimeException  
    extended by java.lang.IllegalArgumentException
     extended by java.lang.NumberFormatException

ঘ। হ্যাঁ, এবং প্রতিটি ব্যতিক্রম যা এটি প্রসারিত করে।

ঘ। একই ব্যতিক্রম ধরা এবং নিক্ষেপ করার দরকার নেই। আপনি এই ক্ষেত্রে একটি নতুন ফাইল সংলাপ প্রদর্শন করতে পারেন।

ঘ। FileNotFoundException হয় ইতিমধ্যে একটি চেক করা ব্যতিক্রম।

৫। যদি এটি প্রত্যাশিত হয় যে পদ্ধতিটি কল someMethodকরতে ব্যাতিক্রম হয়, তবে পরবর্তীটি নিক্ষেপ করা যেতে পারে। এটি কেবল "বল পাস"। আপনি যদি এটি নিজের ব্যক্তিগত পদ্ধতিতে ফেলে দিতে চান এবং এর পরিবর্তে আপনার সর্বজনীন পদ্ধতিতে ব্যতিক্রমটি পরিচালনা করতে চান তবে এর ব্যবহারের উদাহরণ।

একটি ভাল পঠন হ'ল ওরাকল ডকটি নিজেই: http://download.oracle.com/javase/tutorial/essential/exception/runtime.html

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

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

জাভা ভাষা নির্দিষ্টকরণে একটি গুরুত্বপূর্ণ বিট রয়েছে :

থ্রো ক্লজে নামযুক্ত চেক করা ব্যতিক্রম ক্লাসগুলি পদ্ধতি বা কনস্ট্রাক্টরের প্রয়োগকারী এবং ব্যবহারকারীদের মধ্যে চুক্তির অংশ

নীচের লাইন আইএমএইচও হ'ল আপনি যে কোনওটিকে ধরতে পারেনRuntimeException তবে আপনার প্রয়োজন হয় না এবং বাস্তবে বাস্তবায়নের ক্ষেত্রে একই অ-চেক করা ব্যতিক্রমগুলি বজায় রাখা প্রয়োজন হয় না, কারণ সেগুলি চুক্তির অংশ নয়।


ধন্যবাদ. আপনি যখন বুদবুদ করছেন তখন আরও একটি প্রশ্ন exception, আমি কি সঠিক ব্যতিক্রমটি বুদবুদ করব বা এটি ব্যবহার করে মুখোশটি আটকানো উচিত Exception। আমি কিছু লিগ্যাসি কোডের উপরে কোড লিখছি Exceptionএবং সমস্ত জায়গাতেই বুদবুদ হয়ে যাচ্ছি । আমি ভাবছি এটাই যদি সঠিক আচরণ হয়?
থাং ফাম 21

1
@Harry আমি চেয়ে আমাকে উত্তর দিতে আরো জ্ঞান সঙ্গে মানুষের দেওয়া হবে: stackoverflow.com/questions/409563/...
Aleadam

10

1) না, একটি সংখ্যা ফরমেট এক্সসেপশন একটি চেক করা ব্যতিক্রম। যদিও আপনি এটি ধরেছেন (এটি আপনার প্রয়োজন হয় না) কারণ এটি পরীক্ষা করা হয়নি। এটি কারণ এটি একটি সাবক্লাস IllegalArgumentExceptionযার একটি সাবক্লাসRuntimeException

2) RuntimeExceptionসমস্ত চেক করা ব্যতিক্রমগুলির মূল। এর প্রতিটি সাবক্লাসটি চেক RuntimeExceptionকরা নেই। অন্যান্য সমস্ত ব্যতিক্রম এবং Throwableত্রুটিগুলি বাদে যাচাই করা হয় (যার অধীনে আসেThrowable )।

3/4) আপনি ব্যবহারকারীকে সতর্ক করতে পারেন যে তারা অস্তিত্বহীন ফাইলটি বেছে নিয়েছে এবং একটি নতুন ফাইলের জন্য জিজ্ঞাসা করতে পারে। অথবা কেবলমাত্র ব্যবহারকারীকে অবহিত করেই তারা অবৈধ কিছু প্রবেশ করিয়ে দিয়েছিল।

5) নিক্ষেপ এবং ধরা 'Exception' খারাপ অভ্যাস। তবে আরও সাধারণভাবে, আপনি অন্যান্য ব্যতিক্রমগুলি ছুঁড়ে ফেলতে পারেন যাতে কলকারী কীভাবে এটি মোকাবেলা করবেন তা সিদ্ধান্ত নিতে পারে। উদাহরণস্বরূপ, আপনি যদি কিছু ফাইল ইনপুট পড়তে পরিচালনা করতে কোনও লাইব্রেরি লিখে থাকেন এবং আপনার পদ্ধতিটি একটি অস্তিত্বহীন ফাইলটি পাস করেছে তবে কীভাবে এটি পরিচালনা করবেন আপনার কোনও ধারণা নেই। কলকারী কি আবার জিজ্ঞাসা করতে বা ছেড়ে দিতে চায়? সুতরাং আপনি ব্যতিক্রমটিকে কলারের কাছে ফিরে যান।

অনেক ক্ষেত্রে, একটি unchecked Exceptionঘটে থাকে কারণ প্রোগ্রামার ইনপুটগুলি যাচাই করে না ( NumberFormatExceptionআপনার প্রথম প্রশ্নের ক্ষেত্রে)। এ কারণেই তাদের ধরার জন্য এটির optionচ্ছিক, কারণ ex ব্যতিক্রমগুলি এড়াতে আরও মার্জিত উপায় রয়েছে।


ধন্যবাদ. আপনি যখন বুদবুদ করছেন তখন আরও একটি প্রশ্ন exception, আমি কি সঠিক ব্যতিক্রমটি বুদবুদ করব বা এটি ব্যবহার করে মুখোশটি আটকানো উচিত Exception। আমি কিছু লিগ্যাসি কোডের উপরে কোড লিখছি Exceptionএবং সমস্ত জায়গাতেই বুদবুদ হয়ে যাচ্ছি । আমি ভাবছি এটাই যদি সঠিক আচরণ হয়?
থাং ফাম 21

হয় আপনি কেবল নিজের পদ্ধতিটিও ব্যতিক্রম ছোঁড়াতে পারেন (যা আদর্শ নয়)। অথবা এক্সেপশন ধরুন এবং আরও ভাল ব্যতিক্রম (যেমন আইওএক্সেপশন বা কিছু) নিক্ষেপ করুন। সমস্ত ব্যতিক্রম একটি 'কারণ' হিসাবে তাদের নির্মাতায় একটি ব্যতিক্রম নিতে পারে, সুতরাং আপনার এটি ব্যবহার করা উচিত।
dontocsata

8

চেক করা হয়েছে - হওয়ার সম্ভাবনা রয়েছে। সংকলন সময় চেক করা হয়েছে।

উদাহরণস্বরূপ .. ফাইলঅ্যাপেরেশনস

আনচেকড - খারাপ ডেটার কারণে। রান টাইমে চেক করা হয়েছে।

যেমন ..

String s = "abc";
Object o = s;
Integer i = (Integer) o;

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Sample.main(Sample.java:9)

এখানে ব্যতিক্রমগুলি খারাপ ডেটার কারণে এবং কোনওভাবেই এটি সংকলনের সময় নির্ধারণ করা যায় না।


6

জেভিএম এবং এর সংস্থান সম্পর্কিত সংস্থানসমূহ (ফাইল / ডিবি / স্ট্রিম / সকেট ইত্যাদি) দ্বারা সংকলনের সময় পরীক্ষিত ব্যতিক্রমগুলি পরীক্ষা করা হয়। পরীক্ষিত ব্যতিক্রমের উদ্দেশ্যটি হ'ল সংকলন করার সময় যদি সংস্থানগুলি পাওয়া যায় না তবে অ্যাপ্লিকেশনটির এটি ধরা / শেষ অবধি ব্লকটিতে হ্যান্ডেল করার জন্য একটি বিকল্প আচরণের সংজ্ঞা দেওয়া উচিত।

চেক করা ব্যতিক্রমগুলি সম্পূর্ণরূপে প্রোগ্রাম্যাটিক ত্রুটি, ভুল গণনা, নাল ডেটা বা ব্যবসায়ের যুক্তিতে ব্যর্থতা রানটাইম ব্যতিক্রম হতে পারে। কোডে চেক করা ব্যতিক্রমগুলি পরিচালনা করতে / ধরতে একেবারে সূক্ষ্ম।

Http://coder2design.com/java-interview-questions/ থেকে নেওয়া ব্যাখ্যা


5

চেক করা এবং চেক করা ব্যতিক্রমগুলির মধ্যে পার্থক্য সম্পর্কে আমার পরম প্রিয় বর্ণনা জাভা টিউটোরিয়াল ট্রেইল নিবন্ধ, " চেক না করা ব্যতিক্রম - বিতর্ক " দ্বারা সরবরাহ করা হয়েছে (এই পোস্টে সমস্ত প্রাথমিক প্রাপ্তির জন্য দুঃখিত - তবে, ওহে, বেসিকগুলি কখনও কখনও সেরা হয়):

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

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

বাকীটি তখন যৌক্তিক হয়ে ওঠে: কম্পাইলারটি কোন ব্যতিক্রমগুলির কাছে আমার স্পষ্টভাবে প্রতিক্রিয়া আশা করবে? আপনি যা থেকে ক্লায়েন্টটি পুনরুদ্ধার করবেন বলে আশা করেন।


5

চূড়ান্ত প্রশ্নের উত্তর দেওয়ার জন্য (অন্যরা উপরে উপরে পুরোপুরি উত্তরে বলে মনে হচ্ছে), "আমি কি ব্যতিক্রমটি ব্যবহার করে সঠিক ব্যতিক্রমটি ফুটিয়ে তুলি বা এটি মাস্ক করব?"

আমি ধরে নিচ্ছি আপনি এর অর্থ কিছু বোঝাতে চাইছেন:

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

না, সর্বদা সম্ভাব্য সুনির্দিষ্ট ব্যতিক্রম বা এর মতো একটি তালিকা ঘোষণা করুন । আপনি আপনার পদ্ধতিটিকে নিক্ষেপ করতে সক্ষম হিসাবে ঘোষণা করেছেন এমন ব্যতিক্রমগুলি হ'ল আপনার পদ্ধতি এবং কলারের মধ্যে থাকা চুক্তির একটি অংশ। নিক্ষেপ করার "FileNotFoundException"অর্থ এটি সম্ভব যে ফাইলের নাম বৈধ নয় এবং ফাইলটি পাওয়া যাবে না; কলকারীর বুদ্ধিমানভাবে এটি পরিচালনা করা দরকার। নিক্ষেপ করার Exceptionঅর্থ "আরে, শ * টি ঘটে De ডিল।" যা খুব দরিদ্র API

প্রথম নিবন্ধের মন্তব্যে কিছু উদাহরণ রয়েছে যেখানে "নিক্ষেপ Exception" একটি বৈধ এবং যুক্তিসঙ্গত ঘোষণা, তবে normalআপনি " " কোড লিখবেন এমন বেশিরভাগ কোডের ক্ষেত্রে এটি তেমন নয় ।


হুবহু, আপনার কোড ডকুমেন্টেশনের পাশাপাশি আপনার সফ্টওয়্যার ব্যবহার করে ব্যক্তিকে সহায়তা করার জন্য আপনার চেক ব্যতিক্রমের ঘোষণার অংশ করুন।
সালভাদোর ভ্যালেন্সিয়া

5

রানটাইম ব্যতিক্রম : রানটাইম ব্যতিক্রমগুলি চেক করা ব্যতিক্রম হিসাবে উল্লেখ করা হচ্ছে। অন্যান্য সমস্ত ব্যতিক্রম চেক ব্যতিক্রমগুলি চেক করা হয় এবং সেগুলি জাভা.এল.আং.রুনটাইম এক্সেপশন থেকে প্রাপ্ত হয় না।

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

জাভা এপিআই-এর বেশ কয়েকটি পদ্ধতি চেক করা ব্যতিক্রম ছুঁড়ে ফেলেছে, তাই আপনি না লিখেছেন এমন পদ্ধতি দ্বারা উত্পন্ন ব্যতিক্রমগুলি মোকাবেলায় আপনি প্রায়শই ব্যতিক্রম হ্যান্ডলার লিখবেন।


3

কেন তারা ব্যতিক্রম বুদ্বুদ আপ করতে দেয়? ত্রুটিটি পরিচালনা করা কি আরও ভাল হয় না? কেন বুদবুদ?

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

দ্রষ্টব্য: ত্রুটি প্রকারটি কী ঘটেছে তার একটি পরিষ্কার বিবরণ দিতে আমরা আমাদের নিজস্ব ব্যতিক্রমী বস্তু তৈরি করতে পারি এবং ক্লায়েন্টের কাছে ফেলে দিতে পারি।


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

3

আমি মনে করি যে পরীক্ষিত ব্যতিক্রমগুলি বিকাশকারীদের পক্ষে একটি বাহ্যিক লাইব্রেরি ব্যবহার করে যা একটি ব্যতিক্রমী পরিস্থিতিতে সেই লাইব্রেরি থেকে কোডটির সাথে ভুল হতে পারে uses

আরো সম্পর্কে পড়তে অবারিত ব্যতিক্রম এখানে বনাম চেক করা http://learnjava.today/2015/11/checked-vs-unchecked-exceptions/


3

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

যখনই চেক করা ব্যতিক্রমগুলি জড়িত থাকে, throws CheckedExceptionকোনও পদ্ধতিতে স্বাক্ষরের কোনও জায়গা আছে ( CheckedExceptionকোনও চেক করা ব্যতিক্রম হতে পারে)। একটি স্বাক্ষর একটি ব্যতিক্রম ছুঁড়ে না, ব্যতিক্রম ছোঁড়া বাস্তবায়নের একটি দিক। ইন্টারফেস, পদ্ধতি স্বাক্ষর, অভিভাবক শ্রেণি, এই সমস্ত কিছুই তাদের বাস্তবায়নের উপর নির্ভর করে না। এখানে পরীক্ষিত ব্যতিক্রমগুলির ব্যবহার (বাস্তবে আপনাকে throwsপদ্ধতিটির স্বাক্ষর হিসাবে ঘোষণা করতে হবে ) এই ইন্টারফেসগুলি প্রয়োগের সাথে আপনার উচ্চ-স্তরের ইন্টারফেসগুলিকে বাধ্যতামূলক করে।

আমি আপনাকে একটি উদাহরণ দেখাতে দিন।

এর মত একটি সুন্দর এবং পরিষ্কার ইন্টারফেস করা যাক

public interface IFoo {
    public void foo();
}

এখন আমরা foo()এই পদ্ধতিগুলির মতো অনেকগুলি প্রয়োগ লিখতে পারি

public class Foo implements IFoo {
    @Override
    public void foo() {
        System.out.println("I don't throw and exception");
    }
}

ক্লাস ফু পুরোপুরি ঠিক আছে। এখন ক্লাস বারে প্রথম প্রচেষ্টা করা যাক

public class Bar implements IFoo {
    @Override
    public void foo() {
        //I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
        throw new InterruptedException();
    }
}

এই ক্লাস বারটি সংকলন করবে না। বাধাপ্রাপ্তি একটি চেক করা ব্যতিক্রম হিসাবে আপনাকে অবশ্যই এটি ক্যাপচার করতে হবে (পদ্ধতি foo () এর অভ্যন্তরে চেষ্টা করে) বা ঘোষণা করতে হবে যে আপনি এটি নিক্ষেপ করছেন ( throws InterruptedExceptionপদ্ধতির স্বাক্ষরে যোগ করা)। যেহেতু আমি এখানে এই ব্যতিক্রম ক্যাপচার করতে চাই না (আমি এটি উপরের দিকে প্রচার করতে চাই যাতে আমি এটির সাথে অন্য কোথাও সঠিকভাবে ডিল করতে পারি), আসুন স্বাক্ষরটি পরিবর্তন করুন ter

public class Bar implements IFoo {
    @Override
    public void foo() throws InterruptedException {
        throw new InterruptedException();
    }
}

এই ক্লাস বারটিও সংকলন করবে না! বারের পদ্ধতি foo () তাদের স্বাক্ষরগুলি পৃথক হওয়ার কারণে IFoo এর পদ্ধতি foo () কে ওভাররাইড করে না। আমি @ ওভাররাইড টীকা মুছে ফেলতে পারি, তবে আমি ইন্টারফেসের মতো আইফুর মতো প্রোগ্রাম করতে চাই IFoo foo;এবং পরে সিদ্ধান্ত নিতে পারি যে আমি কোন প্রয়োগটি পছন্দ করতে চাই, তার মতো foo = new Bar();। যদি বারের পদ্ধতি foo () IFoo এর পদ্ধতি foo কে ওভাররাইড না করে, যখন আমি foo.foo();এটি করি তখন বারের foo () প্রয়োগকরণ কল করবে না।

বারের public void foo() throws InterruptedExceptionওভাররাইড করার জন্য IFoo এর IFoo এর পদ্ধতি স্বাক্ষরে public void foo()যুক্ত throws InterruptedExceptionহওয়া আবশ্যক । এটি অবশ্য আমার ফু ক্লাসে সমস্যা সৃষ্টি করবে, কারণ এটি ফু () পদ্ধতির স্বাক্ষর আইএফও-এর পদ্ধতির স্বাক্ষরের চেয়ে পৃথক। তদ্ব্যতীত, আমি যদি throws InterruptedExceptionFoo এর পদ্ধতি foo () এ যুক্ত করেছিলাম তবে আমি আরও একটি ত্রুটি পেয়ে যাব যে ফু এর পদ্ধতি foo () ঘোষণা করে যে এটি একটি বাধাপ্রাপ্তি ছুঁড়েছে তবুও এটি কখনও বাধাগ্রস্ত এক্সসেপশনকে ছুড়ে না।

যেমন আপনি দেখতে পাচ্ছেন (যদি আমি এই জিনিসগুলি ব্যাখ্যা করার জন্য একটি উপযুক্ত কাজ করেছি), আমি বাধাপ্রাপ্তি মত একটি চেক করা ব্যতিক্রম ছুঁড়ে ফেলেছি তা আমাকে তার ইন্টারফেস IFoo এর একটি বাস্তবায়নের সাথে আবদ্ধ করতে বাধ্য করছে, যার ফলে IFoo এর উপর বিপর্যয় ঘটায় অন্যান্য বাস্তবায়ন!

চেক করা ব্যতিক্রমগুলি খারাপ হওয়ার এটি একটি বড় কারণ। ক্যাপগুলিতে।

একটি সমাধান হ'ল চেক করা ব্যতিক্রম ক্যাপচার করা, এটি একটি চেক করা ব্যতিক্রমগুলিতে মোড়ানো এবং চেক করা ব্যতিক্রম নিক্ষেপ করা।


2
হ্যাঁ, এটি খারাপ কারণ আপনি বলেছিলেন যে আপনি এটি ধরতে চান না। তবে আইএফইওর স্বাক্ষরকে প্রভাবিত না করার জন্য আপনাকে করতে হবে। আমি বরং এটি করব এবং একটি ব্যতিক্রম ধরা এড়াতে আমার সমস্ত ইন্টারফেসের স্বাক্ষরগুলিতে পুনরায় ভারসাম্যের পরিবর্তে অগ্রসর হব (কেবলমাত্র ব্যতিক্রমগুলি বিএডি হওয়ায়)।
সালভাদোর ভ্যালেন্সিয়া

হাঁ আমি একমত. আমি কিছু সম্পর্কে কিছুটা অস্পষ্ট ছিলাম। আমি প্রচারের জন্য ব্যতিক্রম চাই, তাই আমি এর সাথে অন্য কোথাও ডিল করতে পারি। একটি সমাধান হ'ল বাধা-বিপত্তি ধরা এবং একটি চেক করা ব্যতিক্রম ছোঁড়া। অর্থাত্ আমরা চেক করা ব্যতিক্রমগুলি এড়াতে এবং চেক করা ব্যতিক্রমগুলি অতিক্রম করি (এমনকি তারা কেবল একটি মোড়ক হিসাবে বোঝায়)
ব্লুবারটি

"এটি তবে আমার ফু ক্লাসে সমস্যা সৃষ্টি করবে, যেহেতু এটি ফু () পদ্ধতির স্বাক্ষর আইফুর পদ্ধতির স্বাক্ষরের চেয়ে আলাদা"। আমি কেবল আপনার ধারণাটি পরীক্ষা করেছি throws InterruptedExceptionএবং কোনও বাস্তবায়নে কিছু না ফেলে আমরা আইএফও-এর পদ্ধতি স্বাক্ষরে যুক্ত করলেও এটি সংকলন করা সম্ভব । সুতরাং এটি আসলে কোনও সমস্যার কারণ হয় না। যদি কোনও ইন্টারফেসে আপনি প্রতিটি পদ্ধতিতে স্বাক্ষর নিক্ষেপ করেন Exceptionতবে এটি একটি প্রয়োগকে কেবল একটি ব্যতিক্রম নিক্ষেপ বা না ছোঁড়ার পছন্দ দেয় (কোনও ব্যতিক্রম, Exceptionসমস্ত ব্যতিক্রমকে আবশ্যক করে)।
ফ্লাইআউট 91

তবে আমি স্বীকার করি যে এটি বিভ্রান্তিকর হতে পারে কারণ আপনি যখন এ জাতীয় একটি ইন্টারফেস বাস্তবায়ন করবেন এবং "আনপিমিলেটেড পদ্ধতিগুলি যুক্ত করুন" এর মতো কিছুতে ক্লিক করবেন তখন সেগুলি স্বয়ংক্রিয়ভাবে throw Exceptionতাদের স্বাক্ষরে ক্লজটি তৈরি করা হবে , যদিও আপনার বাস্তবায়ন কিছু ফেলবে না বা হতে পারে আরও নির্দিষ্ট ব্যতিক্রম। তবে আমি এখনও মনে করি একটি ইন্টারফেসের পদ্ধতির জন্য সর্বদা ব্যাতিক্রম ছুঁড়ে ফেলা একটি ভাল অনুশীলন কারণ এটি আবার ব্যবহারকারীকে কিছু ফেলে দেওয়ার বা না ফেলে দেওয়ার পছন্দ দেয়।
ফ্লাইআউট 91

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

3
  • জাভা দুটি বিভাগ ব্যতিক্রমের মধ্যে পার্থক্য করে (পরীক্ষিত এবং চেক করা নেই)।
  • জাভা চেক করা ব্যতিক্রমগুলির জন্য একটি ক্যাচ বা ঘোষিত প্রয়োজনীয়তা প্রয়োগ করে।
  • একটি ব্যতিক্রমের ধরণ নির্ধারণ করে যে একটি ব্যতিক্রম চেক বা চেক করা হয়েছে কিনা।
  • subclassesশ্রেণীর প্রত্যক্ষ বা পরোক্ষভাবে সমস্ত ব্যতিক্রমগুলি চেক করা RuntimeException ব্যতিক্রম।
  • শ্রেণি থেকে উত্তরাধিকারসূত্রে প্রাপ্ত Exceptionনা RuntimeExceptionএমন সমস্ত শ্রেণি বিবেচিত হয় checked exceptions
  • ক্লাস ত্রুটি থেকে উত্তরাধিকারী ক্লাসগুলি চেক করা হিসাবে বিবেচিত হয়।
  • সংকলক পদ্ধতিটি ছুড়ে ফেলে কিনা তা নির্ধারণের জন্য প্রতিটি পদ্ধতি কল এবং হ্রাস পরীক্ষা করে checked exception
    • যদি তাই হয় তবে সংকলকটি ব্যতিক্রম ধরা পড়েছে বা একটি থ্রোস ক্লোজে ঘোষিত হয়েছে তা নিশ্চিত করে।
  • ক্যাচ-বা-ডিক্লেয়ারের প্রয়োজনীয়তার ঘোষিত অংশটি পূরণ করতে, যে ব্যতিক্রমটি উত্পন্ন করে তার জন্য অবশ্যই একটি throwsধারা থাকতে হবে checked-exception
  • Exception শ্রেণিগুলি যখন তাদের ধরা বা ঘোষণার জন্য যথেষ্ট গুরুত্বপূর্ণ বলে বিবেচিত হয় তখন তা পরীক্ষা করার জন্য সংজ্ঞায়িত হয়।

2

এখানে একটি সহজ নিয়ম যা আপনাকে সিদ্ধান্ত নিতে সহায়তা করতে পারে। এটি জাভাতে কীভাবে ইন্টারফেস ব্যবহার করা হয় তার সাথে সম্পর্কিত।

আপনার ক্লাসটি নিয়ে যান এবং এর জন্য একটি ইন্টারফেস ডিজাইনের কল্পনা করুন যাতে ইন্টারফেস শ্রেণীর কার্যকারিতা বর্ণনা করে তবে অন্তর্নিহিত বাস্তবায়নটির কোনওটিই (ইন্টারফেস হিসাবে হওয়া উচিত) নয়। আপনি সম্ভবত অন্যভাবে ক্লাস বাস্তবায়ন করতে পারে তা ভান করুন।

ইন্টারফেসের পদ্ধতিগুলি দেখুন এবং তারা ফেলতে পারে এমন ব্যতিক্রমগুলি বিবেচনা করুন:

অন্তর্নিহিত বাস্তবায়ন নির্বিশেষে যদি কোনও পদ্ধতি ব্যতীত কোনও ব্যতিক্রম ছুঁড়ে ফেলা যায় (অন্য কথায় এটি কেবল কার্যকারিতা বর্ণনা করে) তবে সম্ভবত এটি ইন্টারফেসে একটি পরীক্ষিত ব্যতিক্রম হওয়া উচিত।

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

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

আপনার সাধারণত "বুদ্বুদ-আপ" ব্যতিক্রম (ধরুন এবং পুনর্বিবেচনা) করার পরিকল্পনা করা উচিত নয়। হয় ব্যতিক্রম কলারের দ্বারা পরিচালিত হওয়া উচিত (এটি ক্ষেত্রে যাচাই করা হয়) বা এটি উচ্চ স্তরের হ্যান্ডলারের কাছে যেতে হবে (যদি এটি পরীক্ষা না করা হয় তবে এটি সবচেয়ে সহজ)।


2

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


2

সংক্ষেপে, উপরের আপনার মডিউল বা মডিউলগুলি রানটাইম চলাকালীন হ্যান্ডেল করার কথা বলে যাচাই করা ব্যতিক্রম বলে; অন্যরা চেক করা ব্যতিক্রম যা হয় RuntimeExceptionবা হয় Error

এই ভিডিওতে এটি জাভাতে চেক করা এবং চেক করা ব্যতিক্রমগুলি ব্যাখ্যা করেছে:
https://www.youtube.com/watch?v=ue2pOqLaArw


1

এই সমস্ত ব্যতিক্রম চেক করা হয়। চেক করা ব্যতিক্রমগুলি রানটাইম এক্সেপশন এর সাবক্লাস। সিদ্ধান্তগুলি কীভাবে তাদের পরিচালনা করতে হবে তা নয়, এটি আপনার কোডগুলি নিক্ষেপ করা উচিত। আপনি যদি এই সংকলকটি না চান যে আপনি কোনও ব্যতিক্রম পরিচালনা করেন নি তবে আপনি একটি চেক করা (রানটাইম এক্সেক্সশন সাবক্লাস) ব্যতিক্রম ব্যবহার করেন। এগুলি এমন পরিস্থিতিতে বাঁচাতে হবে যা আপনি পুনরুদ্ধার করতে পারবেন না, যেমন মেমরির ত্রুটিগুলি এবং এর মতো।


উম। যদি নম্বর ফোরামএক্সেপশন একটি চেক করা ব্যতিক্রম হয়, যেমন আপনি বলেছেন, এটি রানটাইম এক্সসেপশন থেকে উত্তরাধিকার সূত্রে প্রাপ্তির বিরোধিতা করছে না ?
eis

দুঃখিত, আমি খুব পরিষ্কার ছিল না। আমি ফাইলফটফাউন্ডএক্সেপশনটি উল্লেখ করছিলাম নাম্বার ফর্ম্যাট এক্সেক্সশন নয়। তার # 2 & # 4 এর উপর ভিত্তি করে, দেখে মনে হয়েছিল যেন তিনি মনে করেন যে চেকড বনাম আনচেকড আপনি কীভাবে ব্যতিক্রমটি ধরার পরে তা পরিচালনা করেছেন তার উপর ভিত্তি করে। এটি কীভাবে সংজ্ঞায়িত হয়েছিল তা নয়।

-1

যদি কেউ চেক করা ব্যতিক্রম অপছন্দ করার জন্য আরও একটি প্রমাণের জন্য যত্নশীল হয় তবে জনপ্রিয় জেএসওএন লাইব্রেরির প্রথম কয়েকটি অনুচ্ছেদ দেখুন:

"যদিও এটি একটি চেক করা ব্যতিক্রম, এটি খুব কমই পুনরুদ্ধারযোগ্য Most বেশিরভাগ কলকারীদের এই ব্যতিক্রমটি কেবল একটি চেক না করা ব্যতিক্রমভাবে আবৃত করে পুনর্বিবেচনা করা উচিত:"

সুতরাং বিশ্বে কেন কেউ এই বিকাশকারীদের ব্যতিক্রম পরীক্ষা করে রাখবে, যদি আমাদের পরিবর্তে "কেবল এটি" আবৃত করা উচিত? হাঃ হাঃ হাঃ

http://developer.android.com/reference/org/json/JSONException.html


4
কারণ এটি কেবল বেশিরভাগ কলার, সমস্ত কলকারী নয়, এটি মোড়ানো এবং পুনর্নির্মাণ করা উচিত। ব্যতিক্রমটি যাচাই করা হয়েছে তার অর্থ হ'ল কলকারীকে তারা "সর্বাধিক" কলকারীদের মধ্যে একজন, বা সংখ্যালঘুদের মধ্যে অন্যতম যা ব্যতিক্রম পরিচালনা করতে পারে এবং করা উচিত তা নিয়ে ভাবতে হবে।
ওয়ারেন ডিউ

1
আপনি যদি করেন প্রতিটি কলের জন্য ত্রুটিগুলি পরীক্ষা করতে পছন্দ করেন, সি তে "ফিরে যান" ব্যতিক্রমগুলি আপনার কোডকে দূষিত না করে সাধারণ প্রোগ্রামের প্রয়োগটিকে অস্বাভাবিক থেকে আলাদা করার একটি উপায়। ব্যতিক্রমগুলি নিশ্চিত করে যে আপনি কোনও স্তরে নিঃশব্দে কোনও ত্রুটি উপেক্ষা করতে পারবেন না ।
স্লাওমির

-1

চেক করা ব্যতিক্রম :

  • রানটাইম সময় প্রোগ্রামটি সুষ্ঠুভাবে সম্পাদনের জন্য সংকলক দ্বারা যে ব্যতিক্রমগুলি পরীক্ষা করা হয় তাদের চেকড ব্যতিক্রম বলে।

  • এগুলি সংকলনের সময় ঘটে।

  • এগুলি যদি সঠিকভাবে পরিচালনা না করা হয় তবে তারা সংকলনের সময় ত্রুটি দেবে (ব্যতিক্রম নয়)।
  • রানটাইম এক্সেপশন বাদে ব্যতিক্রম শ্রেণির সমস্ত সাবক্লাস চেক করা ব্যতিক্রম।

    হাইপোথিটিক্যাল উদাহরণ - ধরুন আপনি পরীক্ষার জন্য আপনার বাড়ি ছেড়ে চলে যাচ্ছেন, তবে আপনি যদি নিজের হল টিকিটটি ঘরে বসেছিলেন কিনা তা পরীক্ষা করে নিলে (পরীক্ষার সময়) তবে পরীক্ষার হলে (রানটাইম) কোনও সমস্যা হবে না।

চেক করা ব্যতিক্রম :

  • যে ব্যতিক্রমগুলি সংকলক দ্বারা পরীক্ষা করা হয় না তাদের চেক করা ব্যতিক্রমগুলি বলে।

  • এগুলি রানটাইমের সময় ঘটে।

  • যদি এই ব্যতিক্রমগুলি সঠিকভাবে পরিচালনা না করা হয় তবে তারা সংকলনের সময় ত্রুটি দেয় না। তবে প্রোগ্রামটি সময়কালে রানটাইমে শেষ হয়ে যাবে।

  • রানটাইম এক্সেপশন এবং ত্রুটির সমস্ত সাবক্লাসগুলি চেক করা ব্যতিক্রম।

    হাইপোথিটিক্যাল উদাহরণ - ধরুন আপনি নিজের পরীক্ষার হলে রয়েছেন তবে কোনওভাবে আপনার স্কুলে আগুনের দুর্ঘটনা ঘটেছে (মানে রানটাইম সময়) যেখানে আপনি সেই সময়ে কিছু করতে পারবেন না তবে সতর্কতা (সময় সংকলনের) আগে করা যেতে পারে।


-2

সমস্ত ব্যতিক্রম অবশ্যই ব্যতিক্রম চেক করা উচিত।

  1. চেক না করা ব্যতিক্রমগুলি সীমাহীন গোটো। এবং সীমাবদ্ধ গোটোগুলি একটি খারাপ জিনিস হিসাবে বিবেচিত হয়।

  2. চেক করা ব্যতিক্রমগুলি এনক্যাপসুলেশন বিরতি দেয়। এগুলি সঠিকভাবে প্রক্রিয়া করতে, থ্রোকার এবং ক্যাচারের মধ্যে কল ট্রিতে সমস্ত ফাংশনগুলি বাগগুলি এড়ানোর জন্য অবশ্যই জানতে হবে।

  3. ব্যতিক্রমগুলি ফাংশনে এমন ত্রুটি যা তাদের ফেলে দেয় তবে তাদের প্রক্রিয়াভুক্ত ফাংশনে ত্রুটি নয়। ব্যতিক্রমগুলির উদ্দেশ্য হ'ল প্রোগ্রামটি এটি একটি ত্রুটি কিনা অন্য কোনও প্রসঙ্গে নয় তা সিদ্ধান্ত স্থগিত করে দ্বিতীয় সুযোগ দেওয়া। এটি কেবলমাত্র অন্য প্রসঙ্গেই সঠিক সিদ্ধান্ত নেওয়া যেতে পারে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.