চেষ্টা / শিকার বনাম থ্রো ব্যতিক্রম


117

এই কোড স্টেটমেন্ট সমতুল্য? তাদের মধ্যে কি কোনও পার্থক্য আছে?

private void calculateArea() throws Exception {
    ....do something
}

private void calculateArea() {
    try {
        ....do something
    } catch (Exception e) {
        showException(e);
    }
}

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

1
ক্যাচটিতে "শোএক্সেপশন (ঙ)" না রেখে, আপনি কি জিজ্ঞাসা করছেন যে আপনি কী "ক্যা" এর পরিবর্তে "ছোঁড়া" দিয়েছিলেন (বা চেষ্টা করার চেষ্টা / ধরা একেবারেই নেই)?
ম্যাকগাইভার

উত্তর:


146

হ্যাঁ, একটি বিশাল পার্থক্য আছে - দ্বিতীয়টি ব্যতিক্রমটিকে গ্রাস করে (এটি দেখায়, স্বীকার করে), তবে প্রথমটি এটি প্রচার করতে দেবে। (আমি ধরে নিচ্ছি যে showExceptionএটি পুনর্বিবেচনা করে না))

সুতরাং আপনি যদি প্রথম পদ্ধতিটিতে কল করেন এবং "কিছু করুন" ব্যর্থ হয়, তবে কলকারীকে ব্যতিক্রমটি পরিচালনা করতে হবে। আপনি দ্বিতীয় পদ্ধতি কল এবং "কিছু" ব্যর্থ হলে, তারপর কলার না এ সব একটি ব্যতিক্রম ... যা সাধারণত একটি খারাপ জিনিস, দেখতে হবে না, যদি না showExceptionহয়েছে সত্যি সত্যি ব্যতিক্রম, স্থায়ী যাই হোক না কেন ভুল ছিল ঘাঁটা, এবং সাধারণত নিশ্চিত করেছেন যে calculateAreaতার উদ্দেশ্য অর্জন করেছে।

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


12
আপনি যখন উল্লেখ করেন যে "যদি না এটি সত্যই ব্যতিক্রমটি পরিচালনা করে", তবে এটি একটি দুর্দান্ত বিষয়। আমি কেবল ভেবেছিলাম যে "ব্যতিক্রম" ধরা নিজেই খুব কমই প্রকৃত ব্যতিক্রমের বুদ্ধিমান "পরিচালনা" করার দিকে পরিচালিত করে যার কারণেই লোকেরা আপনাকে সম্ভবত সবচেয়ে সুনির্দিষ্ট ব্যতিক্রম ধরার পরামর্শ দেয়।
বিল কে

17
+1 টি। কারণ জন স্কিটির আরও খ্যাতি দরকার। ওহ, এবং উত্তর খুব ভাল ছিল।
জোনাথন স্পিলার

20

প্রথমটি throws Exception, তাই কলারের হ্যান্ডেল করা দরকার Exception। দ্বিতীয়টি Exceptionঅভ্যন্তরীণভাবে ক্যাচ করে এবং পরিচালনা করে, তাই কলকারীকে কোনও ব্যতিক্রম হ্যান্ডলিং করতে হবে না।


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

9
না, উভয় নিদর্শন প্রয়োজন। যদি আপনার পদ্ধতিটি ব্যতিক্রমটি পরিচালনা করতে পারে তবে দ্বিতীয় প্যাটার্নটি কল করুন, যদি না হয় তবে ফোনকারীকে বিজ্ঞাপিত করার জন্য প্রথমটি ব্যবহার করুন।
আন্দ্রেয়াস ডলক

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

16

হ্যাঁ. যে সংস্করণটি ঘোষিত হয়েছে throws Exceptionতার ব্যতিক্রমটি পরিচালনা করার জন্য কলিং কোডের প্রয়োজন হবে, তবে যে সংস্করণটি স্পষ্টভাবে এটি পরিচালনা করে তা তা করবে না।

অর্থাত্, সহজভাবে:

performCalculation();

বনাম। কলারের কাছে ব্যতিক্রম পরিচালনা করার বোঝা সরিয়ে দেওয়া:

try {
    performCalculation();
catch (Exception e) {
    // handle exception
}

6

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

সাধারণভাবে বলতে গেলে, আপনি সাধারণ ব্যতিক্রম ধরতে চান না। পরিবর্তে, আপনি কেবল নির্দিষ্টগুলি যেমন ধরতে চাইবেন FileNotFoundExceptionবা IOExceptionএগুলি কারণ তারা বিভিন্ন জিনিস বোঝাতে পারে।


3

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

package trycatchvsthrows;

public class Base {
    public void show()
    {
        System.out.println("hello from base");
    }
}

এবং এটি উত্পন্ন শ্রেণি:

package trycatchvsthrows;

public class Derived extends Base {

    @Override
    public void show()   {
        // TODO Auto-generated method stub
        super.show();

        Thread thread= new Thread();
        thread.start();
        try {
            thread.sleep(100);
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

        // thread.sleep(10);
        // here we can not use public void show() throws InterruptedException 
        // not allowed
    }
}

থ্রেড.স্লিপ () এ কল করতে হলে আমরা চেষ্টা-ধরা ব্যবহার করতে বাধ্য হই, এখানে আমরা ব্যবহার করতে পারি না:

 public void show() throws InterruptedException

কারণ ওভাররাইড পদ্ধতিটি অতিরিক্ত ব্যতিক্রম ছুঁড়ে ফেলতে পারে না।


আমি বিশ্বাস করি যে সবাই এই সতর্কতা সম্পর্কে সচেতন নয় is ভাল পয়েন্ট।
ivanleoncz

1

আমি ধরে নিয়েছি যে "অভিন্ন" দ্বারা আপনি আচরণের কথা উল্লেখ করছেন।

কোনও ক্রিয়াকলাপের আচরণ দ্বারা নির্ধারিত হয়:

1) প্রত্যাবর্তিত মান

2) নিক্ষিপ্ত ব্যতিক্রম

3) পার্শ্ব প্রতিক্রিয়া (অর্থাত, গাদা পরিবর্তন করা, ফাইল সিস্টেম ইত্যাদি)

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

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

--edit--

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


1

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

উদাহরণ:

class A{
public void myMethod() throws Exception{
 //do something
}
}

A a=new A();
try{
a.myMethod();
}catch Exception(e){
//handle the exception
}

0

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


0

এই পদ্ধতির কলকারীকে হয় এই ব্যতিক্রমটি ধরতে হবে বা এটিকে তার পদ্ধতির স্বাক্ষরে পুনর্বিবেচনা করার জন্য ঘোষণা করতে হবে।

private void calculateArea() throws Exception {
    // Do something
}

নীচে ট্রাই-ক্যাচ ব্লকের উদাহরণে। ইতিমধ্যে যত্ন নেওয়া হয়েছে বলে এই পদ্ধতির কলকারীকে ব্যতিক্রম পরিচালনা করার বিষয়ে চিন্তা করতে হবে না।

private void calculateArea() {
    try {
        // Do something

    } catch (Exception e) {
        showException(e);
    }
}

0
private void calculateArea() throws Exception {
    ....do something
}

এটি ব্যতিক্রম ছোঁড়ে, সুতরাং কলার সেই ব্যতিক্রমটি পরিচালনা করার জন্য দায়বদ্ধ তবে কলার যদি এই ব্যতিক্রমটি পরিচালনা না করে তবে এটি jvm কে দেওয়া হতে পারে যার ফলস্বরূপ অস্বাভাবিক অবসান হতে পারে।

যদিও দ্বিতীয় ক্ষেত্রে:

private void calculateArea() {
    try {
        ....do something
    } catch (Exception e) {
        showException(e);
    }
}

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

চেষ্টা করা হ'ল প্রস্তাবিত পন্থা।

আইএমও,

  • সংকলককে বোঝানোর জন্য বেশিরভাগ চেক করা ব্যতিক্রম সহ কীওয়ার্ডটি নিক্ষেপ করে তবে এটি প্রোগ্রামের সাধারণ সমাপ্তির গ্যারান্টি দেয় না।

  • কীওয়ার্ডকে
    কলারের কাছে আপত্তি হ্যান্ডলিংয়ের (জেভিএম বা অন্য কোনও পদ্ধতি) দায়িত্ব অর্পণ করে ।

  • থ্রেড কীওয়ার্ডটি কেবলমাত্র চেক ব্যতিক্রমগুলির জন্য প্রয়োজনীয়, চেক না করা ব্যতিক্রমগুলির জন্য থ্রো কীওয়ার্ডের কোনও ব্যবহার নেই।

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