চেষ্টা করা উচিত ... একটি লুপের ভিতরে বা বাইরে গিয়ে ধরা উচিত?

Question

আমার এমন একটি লুপ রয়েছে যা দেখতে এরকম কিছু দেখাচ্ছে:

for (int i = 0; i < max; i++) {
    String myString = ...;
    float myNum = Float.parseFloat(myString);
    myFloats[i] = myNum;
}

এটি এমন একটি পদ্ধতির মূল বিষয়বস্তু যার একমাত্র উদ্দেশ্য ভাসমানদের অ্যারে ফিরিয়ে দেওয়া। আমি nullকোনও ত্রুটি থাকলে এই পদ্ধতিটি ফিরে আসতে চাই , তাই আমি লুপটি একটি try...catchব্লকের ভিতরে রেখেছি :

try {
    for (int i = 0; i < max; i++) {
        String myString = ...;
        float myNum = Float.parseFloat(myString);
        myFloats[i] = myNum;
    }
} catch (NumberFormatException ex) {
    return null;
}

তবে আমি তখন try...catchব্লকটি লুপের ভিতরে রাখার কথা ভেবেছিলাম :

for (int i = 0; i < max; i++) {
    String myString = ...;
    try {
        float myNum = Float.parseFloat(myString);
    } catch (NumberFormatException ex) {
        return null;
    }
    myFloats[i] = myNum;
}

একে অপরের চেয়ে বেশি পছন্দ করার কোনও কারণ, কর্মক্ষমতা বা অন্যথায় কি আছে?

---

সম্পাদনা করুন: conক্যমত্য বলে মনে হচ্ছে এটি চেষ্টা / ক্যাপচারের ভিতরে লুপটি রাখা সম্ভবত নিজের পদ্ধতির ভিতরেই পরিষ্কার। তবে, কোনটি তত দ্রুত তা নিয়ে এখনও বিতর্ক চলছে। কেউ কি এটি পরীক্ষা করে একীভূত উত্তর নিয়ে ফিরে আসতে পারেন?

Comments

আমি পারফরম্যান্স সম্পর্কে জানি না, তবে কোডটি লুপের বাইরে চেষ্টা করে দেখতে পরিষ্কার দেখায়।

— জ্যাক বি নিম্বল

Answer 1

কর্মক্ষমতা:

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

এখানে একটি তথ্যসূত্র: http://www.javaworld.com/javaworld/jw-01-1997/jw-01-hood.html

টেবিলটি নীচে অর্ধপথে বর্ণনা করা হয়েছে।

Comments

ঠিক আছে, তাই আপনি বলছেন নন্দনতত্ত্ব ব্যতীত কোনও পার্থক্য নেই। আপনি একটি উত্স লিঙ্ক করতে পারেন?

— মাইকেল ম্যাইইয়ার্স

ধন্যবাদ। আমি মনে করি 1997 এর পরে জিনিসগুলি পরিবর্তিত হতে পারে তবে তারা এটিকে কম দক্ষ করে তুলবে না ।

— মাইকেল ম্যাইইয়ার্স

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

— টম হাটিন - ২:28

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

— জেফরি এল হুইলেটজ

কোনও পারফরমেন্সের পার্থক্য নেই, কেবলমাত্র ব্যতিক্রম ব্যতীত কোডটি চললে।

— ওনুর বায়াক

Answer 2

পারফরম্যান্স : জেফ্রি তার জবাবে যেমন বলেছিলেন, জাভাতে এটি তেমন কোনও পার্থক্য করে না।

সাধারণত কোডটির পঠনযোগ্যতার জন্য আপনার ব্যতিক্রমটি কোথায় ধরা উচিত তার উপর নির্ভর করে আপনি লুপটি প্রক্রিয়াকরণ রাখতে চান কিনা তার উপর নির্ভর করে।

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

তৃতীয় উপায় : আপনি সর্বদা নিজের স্ট্যাটিক পার্সফ্লোট পদ্ধতিটি লিখতে পারেন এবং আপনার লুপের পরিবর্তে সেই পদ্ধতিতে ব্যতিক্রম হ্যান্ডলিংয়ের বিষয়টি মোকাবেলা করতে পারেন। ব্যতিক্রম হ্যান্ডলিং লুপ নিজেই বিচ্ছিন্ন করা!

class Parsing
{
    public static Float MyParseFloat(string inputValue)
    {
        try
        {
            return Float.parseFloat(inputValue);
        }
        catch ( NumberFormatException e )
        {
            return null;
        }
    }

    // ....  your code
    for(int i = 0; i < max; i++) 
    {
        String myString = ...;
        Float myNum = Parsing.MyParseFloat(myString);
        if ( myNum == null ) return;
        myFloats[i] = (float) myNum;
    }
}

Comments

পুরো বিষয়টা বিস্তারিত বিবেচনা. তিনি দুজনের মধ্যেই প্রথম ব্যতিক্রম থেকে বেরিয়ে আসছেন। আমি প্রথমে একই জিনিস ভেবেছিলাম।

— কোর্ভিন

আমি সচেতন ছিলাম, এ কারণেই আমি তার ক্ষেত্রে বলেছিলাম, যেহেতু তিনি যখন ফিরে আসছেন তখন যখন কোনও সমস্যায় পড়ে তখন আমি বাইরের ক্যাপচারটি ব্যবহার করব। স্পষ্টতার জন্য, আমি সেই নিয়মটি ব্যবহার করতাম ...

— রায় হেইস

দুর্দান্ত কোড, তবে দুর্ভাগ্যক্রমে জাভাতে প্যারামিটারের বিলাসিতা নেই।

— মাইকেল ম্যাইইয়ার্স

ByRef? আমি জাভা ছুঁয়েছি এতদিন!

— রায় হেইস

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

— রায় হেইস

Answer 3

ঠিক আছে, জেফরি এল হুইটলেজ বলেছিলেন যে কোনও পারফরম্যান্সের পার্থক্য নেই (1997 হিসাবে), আমি গিয়ে এটি পরীক্ষা করেছিলাম। আমি এই ছোট মানদণ্ড চালিয়েছি:

public class Main {

    private static final int NUM_TESTS = 100;
    private static int ITERATIONS = 1000000;
    // time counters
    private static long inTime = 0L;
    private static long aroundTime = 0L;

    public static void main(String[] args) {
        for (int i = 0; i < NUM_TESTS; i++) {
            test();
            ITERATIONS += 1; // so the tests don't always return the same number
        }
        System.out.println("Inside loop: " + (inTime/1000000.0) + " ms.");
        System.out.println("Around loop: " + (aroundTime/1000000.0) + " ms.");
    }
    public static void test() {
        aroundTime += testAround();
        inTime += testIn();
    }
    public static long testIn() {
        long start = System.nanoTime();
        Integer i = tryInLoop();
        long ret = System.nanoTime() - start;
        System.out.println(i); // don't optimize it away
        return ret;
    }
    public static long testAround() {
        long start = System.nanoTime();
        Integer i = tryAroundLoop();
        long ret = System.nanoTime() - start;
        System.out.println(i); // don't optimize it away
        return ret;
    }
    public static Integer tryInLoop() {
        int count = 0;
        for (int i = 0; i < ITERATIONS; i++) {
            try {
                count = Integer.parseInt(Integer.toString(count)) + 1;
            } catch (NumberFormatException ex) {
                return null;
            }
        }
        return count;
    }
    public static Integer tryAroundLoop() {
        int count = 0;
        try {
            for (int i = 0; i < ITERATIONS; i++) {
                count = Integer.parseInt(Integer.toString(count)) + 1;
            }
            return count;
        } catch (NumberFormatException ex) {
            return null;
        }
    }
}

কোনও কিছু যাতে অন্তর্ভুক্ত না হয় তা নিশ্চিত করতে আমি জাভাপ ব্যবহার করে ফলাফলের বাইকোডটি পরীক্ষা করেছিলাম।

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

অতএব, একমাত্র বিবেচনা হ'ল যা পরিষ্কার দেখায়। আমি দেখতে পেলাম যে দ্বিতীয় উপায়টি কুরুচিপূর্ণ, তাই আমি প্রথম পথে বা রে হেইসের পথে আটকে থাকব ।

Comments

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

— থমাস ডব্লিউ

Answer 4

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

Integer j = 0;
    try {
        while (true) {
            ++j;

            if (j == 20) { throw new Exception(); }
            if (j%4 == 0) { System.out.println(j); }
            if (j == 40) { break; }
        }
    } catch (Exception e) {
        System.out.println("in catch block");
    }

যখন লুপটি ট্রাই ক্যাচ ব্লকের ভিতরে রয়েছে তখন ভেরিয়েবল 'জে' বৃদ্ধি হয় যতক্ষণ না এটি 40 টি হিট হয়, জে মোড 4 শূন্য হলে মুদ্রিত হয় এবং জে 20 টি আঘাত করলে একটি ব্যতিক্রম ছুঁড়ে দেওয়া হয়।

কোনও বিবরণের আগে, এখানে অন্য উদাহরণ:

Integer i = 0;
    while (true) {
        try {
            ++i;

            if (i == 20) { throw new Exception(); }
            if (i%4 == 0) { System.out.println(i); }
            if (i == 40) { break; }

        } catch (Exception e) { System.out.println("in catch block"); }
    }

উপরের মত একই যুক্তি, কেবল পার্থক্য হ'ল চেষ্টা / ধরার ব্লকটি এখন লুপের ভিতরে রয়েছে।

এখানে আউটপুট আসে (চেষ্টা / ধরার সময়):

4
8
12 
16
in catch block

এবং অন্যান্য আউটপুট (চেষ্টা করুন / যখন ধরুন):

4
8
12
16
in catch block
24
28
32
36
40

সেখানে আপনার বেশ উল্লেখযোগ্য পার্থক্য রয়েছে:

চেষ্টা / ধরার সময় লুপ থেকে বিরতি

লুপটিকে সচল রাখার সময় চেষ্টা করুন / ধরুন

Comments

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

— গ্যালাক্সি

Answer 5

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

এই সামান্য পরিবর্তিত উদাহরণ বিবেচনা করুন:

public static void main(String[] args) {
    String[] myNumberStrings = new String[] {"1.2345", "asdf", "2.3456"};
    ArrayList asNumbers = parseAll(myNumberStrings);
}

public static ArrayList parseAll(String[] numberStrings){
    ArrayList myFloats = new ArrayList();

    for(int i = 0; i < numberStrings.length; i++){
        myFloats.add(new Float(numberStrings[i]));
    }
    return myFloats;
}

আপনি যদি কোনও ত্রুটি (মূল উদাহরণের মতো) থেকে থাকে তবে পার্সএল () পদ্ধতিটি বাতিল করে দিতে চান, আপনি চেষ্টা করে / বাইরের দিকে ক্যাচটি রাখবেন:

public static ArrayList parseAll1(String[] numberStrings){
    ArrayList myFloats = new ArrayList();
    try{
        for(int i = 0; i < numberStrings.length; i++){
            myFloats.add(new Float(numberStrings[i]));
        }
    } catch (NumberFormatException nfe){
        //fail on any error
        return null;
    }
    return myFloats;
}

বাস্তবে, আপনার সম্ভবত শূন্যের পরিবর্তে এখানে একটি ত্রুটি ফিরে পাওয়া উচিত, এবং সাধারণত আমি একাধিক রিটার্ন পাওয়া পছন্দ করি না তবে আপনি ধারণাটি পান।

অন্যদিকে, আপনি যদি সমস্যাগুলি কেবল উপেক্ষা করতে চান এবং স্ট্রিংগুলি যা কিছু পারেন পার্স করতে চান, তবে আপনি লুপটির অভ্যন্তরে চেষ্টা / ক্যাপচারটি রাখবেন:

public static ArrayList parseAll2(String[] numberStrings){
    ArrayList myFloats = new ArrayList();

    for(int i = 0; i < numberStrings.length; i++){
        try{
            myFloats.add(new Float(numberStrings[i]));
        } catch (NumberFormatException nfe){
            //don't add just this one
        }
    }

    return myFloats;
}

Comments

এ কারণেই আমি বলেছিলাম "যদি আপনি কেবল কোনও খারাপ মান ধরতে চান তবে প্রসেসিং চালিয়ে যেতে চান তবে এটি ভিতরে দিন।"

— রায় হেইস

Answer 6

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

Comments

এই বিশেষ ক্ষেত্রে এটি সত্য নয় (আমি ক্যাচ ব্লকে ফিরে আসছি), তবে সাধারণভাবে মনে রাখা ভাল thing

— মাইকেল ম্যাইইয়ার্স

Answer 7

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

Answer 8

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

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

Answer 9

আপনার উদাহরণগুলিতে কোনও কার্যকরী পার্থক্য নেই। আমি আপনার প্রথম উদাহরণটি আরও পাঠযোগ্য।

Answer 10

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

অন্য নোটে আপনার সম্ভবত ফ্লোটটি দেখা উচিত ry ট্রাইপার্স বা রূপান্তর করুন Tটোফ্লোট।

Answer 11

আপনি যদি চেষ্টা করে / লুপটির ভিতরে রাখেন তবে আপনি ব্যতিক্রমের পরে লুপিং চালিয়ে যাবেন। আপনি যদি এটিকে লুপের বাইরে রাখেন তবে ব্যতিক্রম ছড়িয়ে যাওয়ার সাথে সাথে আপনি থামতে পারবেন।

Comments

ঠিক আছে, আমি ব্যতিক্রম বাদ দিয়ে ফিরছি, সুতরাং এটি আমার ক্ষেত্রে প্রক্রিয়া চালিয়ে যাবে না।

— মাইকেল ম্যাইইয়ার্স

Answer 12

আমার দৃষ্টিকোণ চেষ্টা করা হবে / সঠিক ব্লকগুলি হ্যান্ডলিংয়ের বীমা করার জন্য প্রয়োজনীয় ব্লকগুলি প্রয়োজনীয়, তবে এই জাতীয় ব্লক তৈরির কার্যকারিতা জড়িত। যেহেতু, লুপগুলিতে নিবিড় পুনরাবৃত্তিমূলক গণনা থাকে, তাই লুপের ভিতরে চেষ্টা / ধরার ব্লকগুলি রাখার পরামর্শ দেওয়া হয় না। অতিরিক্ত হিসাবে, মনে হয় যেখানে এই অবস্থাটি ঘটে, এটি প্রায়শই "ব্যতিক্রম" বা "রানটাইম এক্সেকশন" হয় যা ধরা পড়ে। কোডে ধরা রানটাইম এক্সেপশন এড়ানো উচিত। আবার আপনি যদি কোনও বড় সংস্থায় কাজ করেন তবে সেই ব্যতিক্রমটি সঠিকভাবে লগ করা বা রানটাইম ব্যতিক্রম ঘটতে বন্ধ করা অপরিহার্য। এই বিবরণ পুরো পয়েন্টPLEASE AVOID USING TRY-CATCH BLOCKS IN LOOPS

Answer 13

চেষ্টা / ক্যাচের জন্য একটি বিশেষ স্ট্যাক ফ্রেম সেটআপ করা অতিরিক্ত ওভারহেড যুক্ত করে, তবে জেভিএম আপনি ফিরে আসছেন এবং এটি এখুনি অনুকূল করে ফেলেছে তা সনাক্ত করতে সক্ষম হতে পারে।

পুনরাবৃত্তির সংখ্যার উপর নির্ভর করে পারফরম্যান্স পার্থক্য সম্ভবত নগণ্য হবে।

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

যদি কোনও সুযোগ থাকে যে আপনি কোনও অবৈধ সংখ্যা না থাকলে প্রস্থান করার পরিবর্তে প্রসেসিংটি চালিয়ে যেতে চান, তবে আপনি কোডটি লুপের ভিতরে থাকতে চান।

Answer 14

যদি এটি এর ভিতরে থাকে, তবে আপনি বাহিরের একবারের বিপরীতে চেষ্টা করে / ধরুন কাঠামোটির ওভারহেড অর্জন করতে পারেন।

---

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

Comments

আপনি কি ওভারহেডের উপরে একটু বিস্তারিত বলতে পারবেন?

— মাইকেল ম্যাইইয়ার্স

ঠিক আছে, কিন্তু জেফ্রি এল Whitledge আছে বলে কোন অতিরিক্ত ওভারহেড। আপনি কি এমন কোনও উত্স সরবরাহ করতে পারেন যা বলে যে আছে?

— মাইকেল ম্যাইইয়ার্স

ব্যয়টি ছোট, প্রায় নগন্য, তবে এটি সেখানে রয়েছে - প্রতিটি কিছুরই একটি ব্যয় থাকে। নেট। এনট সম্পর্কিত প্রোগ্রামার হ্যাভেন ( tiny.cc/ZBX1b ) এর একটি ব্লগ নিবন্ধ এখানে এবং জাভা ( tiny.cc/BV2hS ) সম্পর্কিত রেহাত সাবিকের একটি নিউজগ্রুপ পোস্ট এখানে রয়েছে

— স্টিফেন রাইটন

আমি দেখছি ... সুতরাং এখন প্রশ্নটি হল, চেষ্টা / ধরতে প্রবেশের ক্ষেত্রে কী ব্যয় হয় (যে ক্ষেত্রে এটি লুপের বাইরে হওয়া উচিত), বা চেষ্টা / ধরার সময়কালের জন্য এটি স্থির হয় (এটি ক্ষেত্রে এটির ক্ষেত্রে) লুপের ভিতরে থাকা উচিত)? আপনি বলছেন এটি # 1। এবং আমি এখনও সম্পূর্ণরূপে বিশ্বাস করছি সেখানে হয় একটি খরচ।

— মাইকেল ম্যাইইয়ার্স

এই গুগল বুক অনুসারে ( tinyurl.com/3pp7qj ), "সর্বশেষতম ভিএমগুলি কোনও জরিমানা দেখায় না"।

— মাইকেল

Answer 15

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

Comments

ভুল! ব্যতিক্রমগুলির বিষয়টি হ'ল কোনও "ত্রুটি" দেখা দিলে কোন ব্যতিক্রমী আচরণ গ্রহণ করা উচিত তা নির্ধারণ করা। এইভাবে অভ্যন্তরীণ বা বাহ্যিক চেষ্টা / ক্যাচ ব্লক নির্বাচন করা আপনি কীভাবে লুপ চিকিত্সা পরিচালনা করতে চান তার উপর নির্ভর করে।

— গ্যাজেট

প্রাক-ব্যতিক্রম ত্রুটিযুক্ত চিকিত্সাগুলির সাথে সমানভাবে এটি করা যেতে পারে যেমন চারপাশে "ত্রুটি ঘটেছে" পতাকা পাস করার মতো।

— wnoise

Answer 16

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

বিবেচনা:

try {
   // parse
} catch (NumberFormatException nfe){
   throw new RuntimeException("Could not parse as a Float: [" + myString + 
                              "] found at index: " + i, nfe);
} 

প্রয়োজনের সময় আপনি যতটা সম্ভব তথ্য সহ এটির মতো একটি ব্যতিক্রমকে সত্যই প্রশংসা করবেন।

Comments

হ্যাঁ, এটিও একটি বৈধ পয়েন্ট। আমার ক্ষেত্রে আমি একটি ফাইল থেকে পড়ছি, সুতরাং আমার সত্যিকারের দরকার কেবল সেই স্ট্রিং যা পার্স করতে ব্যর্থ হয়েছিল। সুতরাং আমি অন্য একটি ব্যতিক্রম ছুঁড়ানোর পরিবর্তে System.out.println (প্রাক্তন) করেছি (আমি যতটা আইনী হিসাবে ফাইলের পার্স করতে চাই)।

— মাইকেল ময়র্স

Answer 17

0.02cব্যতিক্রম হ্যান্ডলিংয়ের অবস্থান কোথায় রাখার সাধারণ সমস্যাটি দেখার সময় আমি দুটি নিজস্ব প্রতিযোগিতামূলক বিবেচনা যুক্ত করতে চাই :

1. "বৃহত্তর" try-catchব্লকের দায়িত্ব (অর্থাত্ আপনার ক্ষেত্রে লুপের বাইরে) এর অর্থ হ'ল কোনও পরে কোড পরিবর্তন করার সময়, আপনি ভুলভাবে একটি লাইন যুক্ত করতে পারেন যা আপনার বিদ্যমান catchব্লক দ্বারা পরিচালিত হয় ; সম্ভবত অনিচ্ছাকৃতভাবে। আপনার ক্ষেত্রে, এটি সম্ভবত কম কারণ আপনি স্পষ্টতই একটি ধরছেনNumberFormatException

2. "সংকীর্ণ" try-catchব্লকের দায়িত্ব , আরও কঠিন রিফ্যাক্টরিং হয়ে ওঠে। বিশেষত যখন (আপনার ক্ষেত্রে হিসাবে) আপনি catchব্লকের ( return nullবিবৃতি) থেকে কোনও "অ-স্থানীয়" নির্দেশনাটি প্রয়োগ করছেন ।

Answer 18

ব্যর্থতা পরিচালনার উপর এটি নির্ভর করে। আপনি যদি কেবল ত্রুটি উপাদানগুলি এড়িয়ে যেতে চান তবে ভিতরে চেষ্টা করুন:

for(int i = 0; i < max; i++) {
    String myString = ...;
    try {
        float myNum = Float.parseFloat(myString);
        myFloats[i] = myNum;
    } catch (NumberFormatException ex) {
        --i;
    }
}

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

Answer 19

আমি আমার 0.02 ডলার রাখব put কখনও কখনও আপনি পরে আপনার কোডে "অবশেষে" যুক্ত করার প্রয়োজন বোধ করেন (কারণ তাদের কোডটি প্রথমবারের মতো নিখুঁত লিখেছেন কে?)। এই ক্ষেত্রে, হঠাৎ লুপের বাইরে চেষ্টা / ধরা আরও বোধগম্য। উদাহরণ স্বরূপ:

try {
    for(int i = 0; i < max; i++) {
        String myString = ...;
        float myNum = Float.parseFloat(myString);
        dbConnection.update("MY_FLOATS","INDEX",i,"VALUE",myNum);
    }
} catch (NumberFormatException ex) {
    return null;
} finally {
    dbConnection.release();  // Always release DB connection, even if transaction fails.
}

কারণ আপনি যদি কোনও ত্রুটি পান বা না পান তবে আপনি কেবল আপনার ডাটাবেস সংযোগটি মুক্তি দিতে (বা আপনার পছন্দসই ধরণের অন্যান্য সংস্থান বেছে নিতে পারেন ...) একবার।

Answer 20

উপরে উল্লিখিত না হওয়া অন্য একটি বিষয় হ'ল প্রতিটি চেষ্টা-ধরাতে স্ট্যাকের কিছুটা প্রভাব রয়েছে যা পুনরাবৃত্ত পদ্ধতিগুলির জন্য জড়িত থাকতে পারে।

যদি পদ্ধতি "বাহ্যিক ()" পদ্ধতিটিকে "অভ্যন্তরীণ ()" কল করে (যা নিজেকে পুনরাবৃত্তভাবে বলতে পারে), যদি সম্ভব হয় তবে পদ্ধতিটিকে "বাইরের ()" তে চেষ্টা করার চেষ্টা করুন। একটি সহজ "স্ট্যাক ক্র্যাশ" উদাহরণ যা আমরা পারফরম্যান্স ক্লাসে ব্যবহার করি যখন ট্র্যাচ-ক্যাচটি অভ্যন্তরীণ পদ্ধতিতে হয় এবং প্রায় 11,600 এ বাইরের পদ্ধতিতে থাকে তখন প্রায় 6,400 ফ্রেমে ব্যর্থ হয়।

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

Answer 21

আপনি যদি প্রতিটি পুনরাবৃত্তির জন্য ব্যতিক্রমটি ধরতে চান, বা কোন পুনরাবৃত্তিটি ব্যতিক্রম হয় কিনা তা পরীক্ষা করে দেখুন এবং প্রতিটি ব্যতিক্রমকে এরর্টিয়নে ধরতে চান, চেষ্টা করুন ... লুপের ভিতরে ধরুন। ব্যতিক্রম ঘটলে এটি লুপটি ভাঙ্গবে না এবং আপনি প্রতিটি পুনরাবৃত্তিতে প্রতিটি লুপ জুড়ে ব্যতিক্রমটি ধরতে পারবেন।

আপনি যদি লুপটি ভাঙ্গতে চান এবং যখনই নিক্ষেপ করা হয় ব্যতিক্রমটি পরীক্ষা করতে চান, চেষ্টা করুন ... লুপটি ধরে ফেলুন। এটি লুপটি ভেঙে ফেলবে এবং ধরার পরে বিবৃতিগুলি কার্যকর করবে (যদি থাকে)।

এটি আপনার প্রয়োজনের উপর নির্ভর করে। আমি চেষ্টা করে ব্যবহার করতে পছন্দ করি ... মোতায়েনের সময় লুপটির অভ্যন্তরে ধরুন, যদি ব্যতিক্রম ঘটে তবে ফলাফলগুলি অস্পষ্ট নয় এবং লুপটি ভেঙে পুরোপুরি কার্যকর হবে না।