ควรลอง ... จับไปข้างในหรือนอกวง?

ฉันมีห่วงที่มีลักษณะเช่นนี้:

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;
}

มีเหตุผลประสิทธิภาพหรืออย่างอื่นที่จะชอบอย่างใดอย่างหนึ่งมากกว่าอื่น ๆ ?

แก้ไข:ฉันทามติดูเหมือนว่าจะสะอาดกว่าที่จะใส่วนเข้าไปในลอง / จับอาจเป็นไปได้ในวิธีการของตัวเอง อย่างไรก็ตามยังมีข้อถกเถียงที่เร็ว ใครบางคนสามารถทดสอบสิ่งนี้และกลับมาพร้อมกับคำตอบแบบรวม?

ประสิทธิภาพ:

ไม่มีความแตกต่างด้านประสิทธิภาพอย่างแน่นอนเมื่อวางโครงสร้าง try / catch ภายในจะมีการใช้งานเป็นตารางรหัสช่วงในโครงสร้างที่สร้างขึ้นเมื่อวิธีการที่เรียกว่า ในขณะที่เมธอดกำลังดำเนินการโครงสร้าง try / catch จะไม่อยู่ในรูปภาพจนกว่าจะเกิดการโยนจากนั้นตำแหน่งของข้อผิดพลาดจะถูกเปรียบเทียบกับตาราง

นี่คือข้อมูลอ้างอิง: http://www.javaworld.com/javaworld/jw-01-1997/jw-01-hood.html

ตารางอธิบายไว้ครึ่งทาง

การแสดง : อย่างที่เจฟฟรีย์พูดไว้ในคำตอบของเขาใน Java มันไม่ได้สร้างความแตกต่างมากนัก

โดยทั่วไปเพื่อความสามารถในการอ่านโค้ดตัวเลือกของคุณในการตรวจจับข้อยกเว้นนั้นขึ้นอยู่กับว่าคุณต้องการให้ลูปประมวลผลต่อไปหรือไม่

ในตัวอย่างของคุณคุณกลับมาเมื่อมีข้อยกเว้น ในกรณีนั้นฉันจะลอง / จับรอบวง หากคุณต้องการเพียงแค่จับค่าที่ไม่ดี แต่ยังดำเนินการอยู่ให้วางไว้ข้างใน

วิธีที่สาม : คุณสามารถเขียนวิธี ParseFloat ของคุณเองได้ตลอดเวลาและมีข้อยกเว้นในการจัดการกับวิธีนั้นแทนที่จะวนซ้ำ ทำให้การจัดการข้อยกเว้นแยกต่างหากเพื่อห่วงตัวเอง!

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;
    }
}

เอาล่ะหลังจากเจฟฟรีย์แอลไวท์เลเดอร์บอกว่าไม่มีความแตกต่างด้านประสิทธิภาพ (ตั้งแต่ปี 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;
        }
    }
}

ฉันตรวจสอบไบต์ที่เกิดขึ้นโดยใช้ javap เพื่อให้แน่ใจว่าไม่มีสิ่งใดเข้ามา

ผลการศึกษาพบว่าสมมติว่าการเพิ่มประสิทธิภาพ JIT ไม่มีนัยสำคัญเจฟฟรีย์ถูกต้อง ; มีอย่างไม่แตกต่างกันประสิทธิภาพการทำงานบน Java 6 ลูกค้าอาทิตย์ VM (ฉันไม่ได้มีการเข้าถึงรุ่นอื่น ๆ ) ความแตกต่างของเวลาทั้งหมดอยู่ในคำสั่งของไม่กี่มิลลิวินาทีในการทดสอบทั้งหมด

ดังนั้นข้อพิจารณาเดียวคือสิ่งที่ดูดีที่สุด ผมพบว่าวิธีที่สองคือน่าเกลียดดังนั้นฉันจะติดทั้งสองวิธีแรกหรือทางเรย์เฮย์ส

ในขณะที่ประสิทธิภาพการทำงานอาจเหมือนกันและสิ่งที่ "ดู" ดีขึ้นเป็นส่วนตัวมาก แต่ก็ยังมีความแตกต่างใหญ่ในการทำงาน นำตัวอย่างต่อไปนี้:

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");
    }

ขณะที่ลูปอยู่ใน try catch block ตัวแปร 'j' จะเพิ่มขึ้นจนกว่าจะถึง 40 พิมพ์ออกมาเมื่อ j mod 4 เป็นศูนย์และมีการโยนข้อยกเว้นเมื่อ j เข้าชม 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"); }
    }

ตรรกะเดียวกับข้างต้นข้อแตกต่างก็คือตอนนี้บล็อก try / catch อยู่ในขณะที่ลูป

เอาท์พุทมาที่นี่ (ในขณะที่ลอง / จับ):

4
8
12 
16
in catch block

และเอาท์พุทอื่น ๆ (ลอง / จับในขณะที่):

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

ที่นั่นคุณมีความแตกต่างค่อนข้างมาก:

ในขณะที่พยายาม / จับแยกออกจากวง

ลอง / จับในขณะที่ยังใช้งานลูป

ฉันเห็นด้วยกับประสิทธิภาพและโพสต์ที่อ่านได้ทั้งหมด อย่างไรก็ตามมีหลายกรณีที่มันสำคัญจริงๆ คู่อื่น ๆ พูดถึงสิ่งนี้ แต่อาจดูตัวอย่างได้ง่ายขึ้น

ลองพิจารณาตัวอย่างที่แก้ไขเล็กน้อยนี้:

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;
}

หากคุณต้องการให้ parseAll () วิธีการคืนค่าเป็นโมฆะหากมีข้อผิดพลาด (เช่นตัวอย่างดั้งเดิม) คุณจะต้องลอง / catch ด้านนอกดังนี้:

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;
}

ในความเป็นจริงคุณควรกลับข้อผิดพลาดที่นี่แทนที่จะเป็นโมฆะและโดยทั่วไปแล้วฉันไม่ชอบมีการส่งคืนหลายครั้ง แต่คุณได้รับความคิด

ในทางกลับกันหากคุณต้องการเพียงแค่เพิกเฉยต่อปัญหาและแยกวิเคราะห์ว่าสามารถใช้ Strings ใดได้บ้างคุณต้องลอง / จับที่ด้านในของลูปดังนี้:

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;
}

ดังที่กล่าวไปแล้วประสิทธิภาพการทำงานเหมือนกัน อย่างไรก็ตามประสบการณ์ของผู้ใช้ไม่จำเป็นต้องเหมือนกัน ในกรณีแรกคุณจะล้มเหลวอย่างรวดเร็ว (เช่นหลังจากเกิดข้อผิดพลาดครั้งแรก) อย่างไรก็ตามถ้าคุณวางบล็อก try / catch ไว้ในลูปคุณสามารถดักจับข้อผิดพลาดทั้งหมดที่จะถูกสร้างขึ้นสำหรับวิธีการโทรที่กำหนด เมื่อแยกอาร์เรย์ของค่าจากสตริงที่คุณคาดว่าจะเกิดข้อผิดพลาดในการจัดรูปแบบมีบางกรณีที่คุณต้องการที่จะสามารถนำเสนอข้อผิดพลาดทั้งหมดให้กับผู้ใช้เพื่อที่พวกเขาไม่จำเป็นต้องลองแก้ไขทีละตัว .

ถ้ามันทั้งหมดหรือไม่มีอะไรล้มเหลวรูปแบบแรกก็สมเหตุสมผล หากคุณต้องการที่จะสามารถประมวลผล / ส่งคืนองค์ประกอบที่ไม่ใช่ความล้มเหลวทั้งหมดคุณต้องใช้แบบฟอร์มที่สอง สิ่งเหล่านั้นจะเป็นเกณฑ์พื้นฐานของฉันสำหรับการเลือกระหว่างวิธีการ ส่วนตัวถ้าเป็นทั้งหมดหรือไม่มีอะไรฉันจะไม่ใช้แบบฟอร์มที่สอง

ตราบใดที่คุณตระหนักถึงสิ่งที่คุณต้องทำให้สำเร็จในลูปคุณสามารถลองจับนอกวง แต่สิ่งสำคัญคือต้องเข้าใจว่าการวนซ้ำนั้นจะจบลงทันทีที่มีข้อยกเว้นเกิดขึ้นและอาจไม่เป็นอย่างที่คุณต้องการเสมอไป นี่เป็นข้อผิดพลาดที่พบบ่อยมากในซอฟต์แวร์ที่ใช้ Java ผู้คนจำเป็นต้องประมวลผลรายการจำนวนมากเช่นการล้างคิวและพึ่งพาข้อความสั่ง try / catch ภายนอกซึ่งจัดการข้อยกเว้นที่เป็นไปได้ทั้งหมด พวกเขายังสามารถจัดการข้อยกเว้นเฉพาะภายในวงและไม่คาดว่าจะเกิดข้อยกเว้นอื่น ๆ จากนั้นหากมีข้อยกเว้นเกิดขึ้นที่ไม่ได้จัดการภายในลูปลูปจะ "preemted" มันจะจบลงก่อนกำหนดและคำสั่ง catch ภายนอกจะจัดการกับข้อยกเว้น

หากลูปมีบทบาทในชีวิตในการลบคิวดังนั้นลูปนั้นน่าจะจบได้ก่อนที่คิวนั้นจะว่างเปล่า ความผิดปกติที่พบบ่อยมาก

ในตัวอย่างของคุณไม่มีความแตกต่างการทำงาน ฉันพบตัวอย่างแรกของคุณอ่านได้มากขึ้น

คุณควรเลือกเวอร์ชั่นด้านนอกมากกว่าเวอร์ชั่นภายใน นี่เป็นเพียงกฎรุ่นที่เฉพาะเจาะจงย้ายสิ่งใด ๆ นอกลูปที่คุณสามารถย้ายออกไปนอกลูป ขึ้นอยู่กับคอมไพเลอร์ IL และ JIT คอมไพเลอร์สองเวอร์ชันของคุณอาจมีหรือไม่มีคุณสมบัติที่แตกต่างกัน

ในบันทึกย่ออื่นคุณอาจดู float.TryParse หรือ Convert.ToFloat

หากคุณลอง / จับภายในวงคุณจะวนลูปหลังจากข้อยกเว้น หากคุณวางไว้นอกวงคุณจะหยุดทันทีที่มีการโยนข้อยกเว้น

มุมมองของฉันคือการลอง / จับบล็อกมีความจำเป็นเพื่อประกันการจัดการข้อยกเว้นที่เหมาะสม แต่การสร้างบล็อกดังกล่าวมีผลต่อประสิทธิภาพ เนื่องจากลูปมีการคำนวณซ้ำ ๆ อย่างเข้มข้นจึงไม่แนะนำให้ใส่บล็อกลอง / จับภายในลูป นอกจากนี้ดูเหมือนว่าเงื่อนไขนี้เกิดขึ้นมักจะเป็น "ข้อยกเว้น" หรือ "RuntimeException" ซึ่งติดอยู่ RuntimeException ที่ติดอยู่ในรหัสควรหลีกเลี่ยง อีกครั้งถ้าหากคุณทำงานใน บริษัท ใหญ่จำเป็นต้องบันทึกข้อยกเว้นนั้นอย่างเหมาะสมหรือหยุดข้อยกเว้นรันไทม์ให้เกิดขึ้น จุดรวมของคำอธิบายนี้คือPLEASE AVOID USING TRY-CATCH BLOCKS IN LOOPS

การตั้งค่ากรอบสแต็กพิเศษสำหรับลอง / จับเพิ่มค่าใช้จ่ายเพิ่มเติม แต่ JVM อาจสามารถตรวจสอบความจริงที่ว่าคุณกำลังกลับมาและเพิ่มประสิทธิภาพนี้ออกไป

ขึ้นอยู่กับจำนวนของการวนซ้ำความแตกต่างของประสิทธิภาพจะมีน้อยมาก

อย่างไรก็ตามฉันเห็นด้วยกับคนอื่น ๆ ที่มีมันอยู่นอกวงทำให้ร่างกายดูห่วงสะอาด

หากมีโอกาสที่คุณจะต้องการดำเนินการต่อด้วยการประมวลผลแทนที่จะออกหากมีหมายเลขที่ไม่ถูกต้องคุณจะต้องการให้โค้ดอยู่ในลูป

หากอยู่ข้างในคุณจะได้รับค่าโสหุ้ยของโครงสร้าง try / catch N ครั้งเมื่อเทียบกับภายนอกเพียงครั้งเดียว

ทุกครั้งที่มีการเรียกใช้โครงสร้างลอง / จับมันจะเพิ่มค่าใช้จ่ายในการดำเนินการของวิธีการ หน่วยความจำและตัวประมวลผลเพียงเล็กน้อยที่จำเป็นในการจัดการกับโครงสร้าง หากคุณใช้วนซ้ำ 100 ครั้งและเพื่อประโยชน์สมมุติสมมุติว่าค่าใช้จ่ายคือ 1 ขีดต่อลองโทร / จับแล้วให้ลอง / จับภายในวงมีค่าใช้จ่ายคุณ 100 เห็บตรงข้ามกับเพียง 1 ขีดถ้ามันเป็น นอกวง

จุดทั้งหมดของข้อยกเว้นคือการสนับสนุนรูปแบบแรก: ให้การจัดการข้อผิดพลาดที่จะรวมและจัดการครั้งเดียวไม่ได้ทันทีในทุกเว็บไซต์ข้อผิดพลาดที่เป็นไปได้

วางไว้ข้างใน คุณสามารถประมวลผลต่อไป (ถ้าคุณต้องการ) หรือคุณสามารถโยนข้อยกเว้นที่เป็นประโยชน์ที่จะบอกลูกค้าถึงค่าของ myString และดัชนีของอาร์เรย์ที่มีค่าที่ไม่ดี ฉันคิดว่า NumberFormatException จะบอกคุณถึงคุณค่าที่ไม่ดี แต่หลักการคือการวางข้อมูลที่เป็นประโยชน์ทั้งหมดไว้ในข้อยกเว้นที่คุณโยน คิดเกี่ยวกับสิ่งที่น่าสนใจสำหรับคุณในโปรแกรมดีบั๊กที่จุดนี้ในโปรแกรม

พิจารณา:

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

ในเวลาที่คุณต้องการคุณจะประทับใจกับข้อยกเว้นเช่นนี้ที่มีข้อมูลมากที่สุดเท่าที่จะเป็นไปได้

ฉันต้องการเพิ่ม0.02cข้อพิจารณาที่แข่งขันกันสองข้อของตัวเองเมื่อดูปัญหาทั่วไปว่าจะจัดการข้อยกเว้นได้ที่ใด:

1. ความรับผิดชอบ "ที่กว้างขึ้น" ของtry-catchบล็อก (เช่นนอกวงในกรณีของคุณ) หมายความว่าเมื่อเปลี่ยนรหัสในภายหลังคุณอาจเพิ่มบรรทัดที่จัดการโดยcatchบล็อกที่มีอยู่ของคุณผิดพลาด อาจไม่ได้ตั้งใจ ในกรณีของคุณสิ่งนี้มีโอกาสน้อยกว่าเนื่องจากคุณกำลังจับNumberFormatException

2. ความรับผิดชอบของtry-catchบล็อกที่"แคบลง" จะทำให้การเปลี่ยนโครงสร้างใหม่ยากขึ้น โดยเฉพาะอย่างยิ่งเมื่อ (ในกรณีของคุณ) คุณกำลังดำเนินการคำสั่ง "นอกท้องถิ่น" จากภายในcatchบล็อก ( return nullคำสั่ง)

ขึ้นอยู่กับความล้มเหลวในการจัดการ หากคุณเพียงต้องการข้ามองค์ประกอบข้อผิดพลาดลองภายใน:

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

ในกรณีอื่น ๆ ฉันอยากลองด้านนอก รหัสอ่านได้ง่ายขึ้นสะอาดขึ้นกว่าเดิม อาจเป็นการดีกว่าที่จะโยน IllegalArgumentException ในกรณีที่เกิดข้อผิดพลาดแทนหากส่งคืน null

ฉันจะใส่เงิน $ 0.02 ในบางครั้งคุณต้องมีการเพิ่ม "ในที่สุด" ในภายหลังในรหัสของคุณ (เพราะใครเคยเขียนรหัสของพวกเขาอย่างสมบูรณ์ในครั้งแรก? ในกรณีเหล่านั้นทันใดนั้นก็เหมาะสมกว่าที่จะลอง / จับนอกวง ตัวอย่างเช่น:

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.
}

เพราะถ้าคุณได้รับข้อผิดพลาดหรือไม่คุณต้องการปล่อยการเชื่อมต่อฐานข้อมูลของคุณ (หรือเลือกประเภทอื่น ๆ ของทรัพยากรที่คุณชื่นชอบ ... ) หนึ่งครั้ง

อีกแง่มุมที่ไม่ได้กล่าวถึงข้างต้นก็คือความจริงที่ว่าทุกการทดลองมีบางส่วนผลกระทบในกองซึ่งจะมีผลกระทบต่อวิธีการเรียกซ้ำ

หากเมธอด "outer ()" เรียกใช้เมธอด "inner ()" (ซึ่งอาจเรียกตัวเองซ้ำ ๆ ) ให้ลองค้นหาวิธีลองจับในเมธอด "outer ()" ถ้าเป็นไปได้ ตัวอย่างง่ายๆ "stack crash" ที่เราใช้ในคลาสประสิทธิภาพล้มเหลวที่ประมาณ 6,400 เฟรมเมื่อ try-catch อยู่ใน method ด้านในและประมาณ 11,600 เมื่ออยู่ในเมธอด outer

ในโลกแห่งความจริงอาจเป็นปัญหาได้หากคุณใช้รูปแบบคอมโพสิตและมีโครงสร้างซ้อนกันขนาดใหญ่ที่ซับซ้อน

หากคุณต้องการที่จะรับการยกเว้นสำหรับการทำซ้ำแต่ละครั้งหรือตรวจสอบสิ่งที่ซ้ำการยกเว้นจะถูกโยนและจับทุกข้อยกเว้นในการ itertaion สถานที่ลอง ... จับภายในวง สิ่งนี้จะไม่ทำลายลูปหากมีข้อยกเว้นเกิดขึ้นและคุณสามารถตรวจจับข้อยกเว้นในแต่ละการวนซ้ำได้ตลอดการวนซ้ำ

หากคุณต้องการแยกลูปและตรวจสอบข้อยกเว้นทุกครั้งที่โยนให้ลองใช้ ... สิ่งนี้จะทำลายลูปและเรียกใช้งานคำสั่งหลังจากตรวจจับ (ถ้ามี)

ทุกอย่างขึ้นอยู่กับความต้องการของคุณ ฉันชอบใช้ try ... catch ภายในลูปในขณะที่ปรับใช้เป็นถ้ามีข้อยกเว้นเกิดขึ้นผลลัพธ์ไม่ชัดเจนและลูปจะไม่หยุดและดำเนินการอย่างสมบูรณ์