หลีกเลี่ยง! = ข้อความสั่งโมฆะ

ผมใช้จำนวนมากที่จะหลีกเลี่ยงobject != nullNullPointerException

มีทางเลือกที่ดีสำหรับสิ่งนี้หรือไม่?

ตัวอย่างเช่นฉันมักจะใช้:

if (someobject != null) {
    someobject.doCalc();
}

การตรวจสอบนี้สำหรับNullPointerExceptionสำหรับsomeobjectวัตถุในตัวอย่างข้างต้น

โปรดทราบว่าคำตอบที่ยอมรับอาจล้าสมัยโปรดดูhttps://stackoverflow.com/a/2386013/12943สำหรับวิธีการล่าสุด

สิ่งนี้สำหรับฉันดูเหมือนว่าเป็นปัญหาที่พบได้ทั่วไปพอสมควรที่ผู้พัฒนาระดับต้นถึงระดับกลางมักเผชิญในบางประเด็น: พวกเขาไม่รู้หรือไม่เชื่อถือสัญญาที่พวกเขาเข้าร่วม นอกจากนี้เมื่อเขียนรหัสของตัวเองพวกเขามักจะพึ่งพาการคืนค่าโมฆะเพื่อระบุสิ่งที่ต้องการให้ผู้โทรตรวจสอบค่า Null

หากต้องการใช้อีกวิธีหนึ่งมีสองกรณีที่การตรวจสอบโมฆะเกิดขึ้น:

1. เมื่อ null เป็นคำตอบที่ถูกต้องในเงื่อนไขของสัญญา และ

2. ในกรณีที่มันไม่ตอบสนองที่ถูกต้อง

(2) เป็นเรื่องง่าย ใช้assertข้อความสั่ง (ยืนยัน) หรืออนุญาตความล้มเหลว (ตัวอย่างเช่น NullPointerException ) การยืนยันเป็นคุณลักษณะ Java ที่มีการใช้งานต่ำซึ่งถูกเพิ่มใน 1.4 ไวยากรณ์คือ:

assert <condition>

หรือ

assert <condition> : <object>

โดยที่<condition>เป็นนิพจน์บูลีนและ<object>เป็นวัตถุที่toString()เอาต์พุตของเมธอดจะรวมอยู่ในข้อผิดพลาด

assertคำสั่งพ่นError( AssertionError) ถ้าเงื่อนไขไม่เป็นความจริง โดยค่าเริ่มต้น Java ละเว้นการยืนยัน คุณสามารถเปิดใช้งานการยืนยันด้วยการส่งตัวเลือก-eaไปที่ JVM คุณสามารถเปิดใช้งานและปิดใช้งานการยืนยันสำหรับแต่ละคลาสและแพ็คเกจ ซึ่งหมายความว่าคุณสามารถตรวจสอบรหัสด้วยการยืนยันในขณะที่การพัฒนาและการทดสอบและปิดการใช้งานในสภาพแวดล้อมการผลิตแม้ว่าการทดสอบของฉันแสดงให้เห็นว่าไม่มีผลกระทบต่อประสิทธิภาพจากการยืนยัน

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

(1) ยากขึ้นเล็กน้อย หากคุณไม่สามารถควบคุมรหัสที่คุณโทรได้แสดงว่าคุณติดขัดอยู่ หาก null เป็นคำตอบที่ถูกต้องคุณต้องตรวจสอบ

หากเป็นโค้ดที่คุณควบคุมได้ (และนี่ก็เป็นเรื่องปกติ) นั่นเป็นเรื่องอื่น หลีกเลี่ยงการใช้ค่า null เป็นคำตอบ ด้วยวิธีที่คืนค่าคอลเลคชันมันง่าย: คืนค่าคอลเลคชั่นที่ว่างเปล่า (หรืออาร์เรย์) แทนค่า Null ที่ค่อนข้างตลอดเวลา

ด้วยการไม่สะสมอาจเป็นเรื่องยาก ลองพิจารณาสิ่งนี้เป็นตัวอย่าง: หากคุณมีอินเตอร์เฟสเหล่านี้:

public interface Action {
  void doSomething();
}

public interface Parser {
  Action findAction(String userInput);
}

ที่ Parser รับอินพุตผู้ใช้แบบ raw และค้นหาสิ่งที่ต้องทำบางทีถ้าคุณกำลังใช้อินเตอร์เฟสบรรทัดคำสั่งสำหรับบางสิ่ง ตอนนี้คุณอาจทำสัญญาว่าจะส่งคืน null ถ้าไม่มีการกระทำที่เหมาะสม นั่นนำไปสู่การตรวจสอบโมฆะที่คุณกำลังพูดถึง

ทางเลือกอื่นคือไม่คืนค่า Null และใช้รูปแบบ Null Objectแทน:

public class MyParser implements Parser {
  private static Action DO_NOTHING = new Action() {
    public void doSomething() { /* do nothing */ }
  };

  public Action findAction(String userInput) {
    // ...
    if ( /* we can't find any actions */ ) {
      return DO_NOTHING;
    }
  }
}

เปรียบเทียบ:

Parser parser = ParserFactory.getParser();
if (parser == null) {
  // now what?
  // this would be an example of where null isn't (or shouldn't be) a valid response
}
Action action = parser.findAction(someInput);
if (action == null) {
  // do nothing
} else {
  action.doSomething();
}

ถึง

ParserFactory.getParser().findAction(someInput).doSomething();

ซึ่งเป็นการออกแบบที่ดีกว่ามากเพราะนำไปสู่รหัสที่กระชับยิ่งขึ้น

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

try {
    ParserFactory.getParser().findAction(someInput).doSomething();
} catch(ActionNotFoundException anfe) {
    userConsole.err(anfe.getMessage());
}

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

public Action findAction(final String userInput) {
    /* Code to return requested Action if found */
    return new Action() {
        public void doSomething() {
            userConsole.err("Action not found: " + userInput);
        }
    }
}

หากคุณใช้ (หรือวางแผนที่จะใช้) Java IDE เช่นJetBrains IntelliJ IDEA , EclipseหรือNetbeansหรือเครื่องมือเช่น findbugs คุณสามารถใช้คำอธิบายประกอบเพื่อแก้ปัญหานี้ได้

โดยทั่วไปคุณได้และ@Nullable@NotNull

คุณสามารถใช้ในวิธีการและพารามิเตอร์เช่นนี้

@NotNull public static String helloWorld() {
    return "Hello World";
}

หรือ

@Nullable public static String helloWorld() {
    return "Hello World";
}

ตัวอย่างที่สองจะไม่รวบรวม (ใน IntelliJ IDEA)

เมื่อคุณใช้helloWorld()ฟังก์ชันแรกในรหัสอื่น:

public static void main(String[] args)
{
    String result = helloWorld();
    if(result != null) {
        System.out.println(result);
    }
}

ตอนนี้ความคิดที่คอมไพเลอร์ IntelliJ จะบอกคุณว่าการตรวจสอบจะไม่ได้ผลเนื่องจากhelloWorld()ฟังก์ชั่นจะไม่กลับมาnullเลยทีเดียว

ใช้พารามิเตอร์

void someMethod(@NotNull someParameter) { }

ถ้าคุณเขียนสิ่งที่ชอบ:

someMethod(null);

สิ่งนี้จะไม่รวบรวม

ตัวอย่างล่าสุดที่ใช้ @Nullable

@Nullable iWantToDestroyEverything() { return null; }

ทำสิ่งนี้

iWantToDestroyEverything().something();

และคุณสามารถมั่นใจได้ว่าสิ่งนี้จะไม่เกิดขึ้น :)

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

ใน IntelliJ IDEA 10.5 ขึ้นไปจะเพิ่มการสนับสนุนสำหรับ@Nullable @NotNullการปรับใช้อื่น ๆ

ดูโพสต์บล็อกที่มีความยืดหยุ่นมากขึ้นและการกำหนดค่า @ Nullable / @ NotNull คำอธิบายประกอบ

หากไม่อนุญาตให้ใช้ค่า null

หากวิธีการของคุณถูกเรียกจากภายนอกให้เริ่มจากสิ่งนี้:

public void method(Object object) {
  if (object == null) {
    throw new IllegalArgumentException("...");
  }

จากนั้นในวิธีที่เหลือคุณจะรู้ว่าobjectไม่เป็นโมฆะ

ถ้ามันเป็นวิธีการภายใน (ไม่ใช่ส่วนหนึ่งของ API) เพียงแค่เอกสารว่ามันไม่สามารถเป็นโมฆะได้

ตัวอย่าง:

public String getFirst3Chars(String text) {
  return text.subString(0, 3);
}

อย่างไรก็ตามหากวิธีการของคุณเพียงแค่ส่งผ่านค่าบนและวิธีต่อไปผ่านไป ฯลฯ มันอาจได้รับปัญหา ในกรณีนั้นคุณอาจต้องการตรวจสอบอาร์กิวเมนต์ตามข้างต้น

ถ้าโมฆะได้รับอนุญาต

สิ่งนี้ขึ้นอยู่กับ หากพบว่าฉันมักจะทำสิ่งนี้:

if (object == null) {
  // something
} else {
  // something else
}

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

ที่จริงแล้วมันหายากสำหรับฉันที่จะใช้สำนวน " if (object != null && ..."

มันอาจจะง่ายกว่าที่จะให้คุณตัวอย่างถ้าคุณแสดงตัวอย่างของที่คุณมักจะใช้สำนวน

ว้าวฉันเกือบจะเกลียดที่จะเพิ่มคำตอบอื่นเมื่อเรามี 57 วิธีที่แตกต่างกันที่จะแนะนำNullObject patternแต่ฉันคิดว่าบางคนที่สนใจในคำถามนี้อาจต้องการที่จะรู้ว่ามีข้อเสนอในตารางสำหรับ Java 7 เพื่อเพิ่ม"ปลอดภัย การจัดการ " - ไวยากรณ์ที่มีความคล่องตัวสำหรับตรรกะ if-not-เท่ากับ-null

ตัวอย่างที่ได้รับจาก Alex Miller มีลักษณะดังนี้:

public String getPostcode(Person person) {  
  return person?.getAddress()?.getPostcode();  
}  

?.หมายถึงเฉพาะ nullde-อ้างอิงระบุซ้ายถ้ามันไม่เป็นโมฆะมิฉะนั้นประเมินที่เหลือของการแสดงออกเป็น บางคนเช่นสมาชิก Java กองดิ๊กกำแพงและผู้มีสิทธิเลือกตั้งที่ Devoxxรักจริงๆข้อเสนอนี้ แต่มีความขัดแย้งมากเกินไปในบริเวณที่มันจริงจะส่งเสริมให้ใช้มากขึ้นของnullเป็นค่าแมวมอง

ปรับปรุง: ข้อเสนออย่างเป็นทางการสำหรับผู้ประกอบการ null ปลอดภัยใน Java 7 ถูกส่งมาภายใต้โครงการเหรียญ ไวยากรณ์แตกต่างจากตัวอย่างด้านบนเล็กน้อย แต่เป็นความคิดเดียวกัน

อัปเดต:ข้อเสนอโอเปอเรเตอร์ที่ปลอดภัยไม่ได้ทำให้เป็น Project Coin ดังนั้นคุณจะไม่เห็นไวยากรณ์นี้ใน Java 7

หากไม่อนุญาตให้ใช้ค่าที่ไม่ได้กำหนด:

คุณอาจกำหนดค่า IDE ของคุณเพื่อเตือนคุณเกี่ยวกับการยกเลิกการอ้างอิงที่อาจเกิดขึ้น เช่นใน Eclipse ดูการตั้งค่า> Java> คอมไพเลอร์> ข้อผิดพลาด / คำเตือน / วิเคราะห์

หากอนุญาตค่าที่ไม่ได้กำหนด:

หากคุณต้องการกำหนด API ใหม่ที่มีค่าที่ไม่ได้กำหนดให้ใช้รูปแบบตัวเลือก (อาจคุ้นเคยกับภาษาที่ใช้งานได้) มันมีข้อดีดังต่อไปนี้:

• มีการระบุไว้อย่างชัดเจนใน API ว่ามีอินพุตหรือเอาต์พุตอยู่หรือไม่
• คอมไพเลอร์บังคับให้คุณจัดการกับเคส "undefined"
• ตัวเลือกที่ monadจึงมีความจำเป็นที่จะต้องตรวจสอบอย่างละเอียด null เพียงใช้แผนที่ / foreach / getOrElse หรือ Combinator คล้ายกับการใช้อย่างปลอดภัยค่าไม่มี(ตัวอย่าง)

Java 8 มีOptionalคลาสในตัว(แนะนำ); สำหรับรุ่นก่อนหน้านี้มีทางเลือกห้องสมุดเช่นฝรั่ง 's OptionalหรือFunctionalJava ' Options แต่ก็เหมือนกับรูปแบบการใช้งานหลายรูปแบบการใช้ตัวเลือกใน Java (แม้ 8) จะส่งผลให้เกิดสำเร็จรูปบางส่วนซึ่งคุณสามารถลดการใช้ภาษา JVM ที่ละเอียดน้อยกว่าเช่น Scala หรือ Xtend

หากคุณต้องจัดการกับ API ซึ่งอาจส่งคืน nullคุณไม่สามารถทำอะไรได้มากใน Java Xtend และ Groovy มีตัวดำเนินการ Elvis ?:และตัวดำเนินการ dereference แบบ null-safe ?.แต่โปรดทราบว่าสิ่งนี้จะคืนค่า null ในกรณีของการอ้างอิงแบบ null ดังนั้นจึงเป็นเพียง "defers" การจัดการค่า null ที่เหมาะสม

สำหรับสถานการณ์นี้เท่านั้น -

ไม่ตรวจสอบว่าตัวแปรเป็นโมฆะก่อนที่จะเรียกใช้เมธอด equals (สตริงเปรียบเทียบตัวอย่างด้านล่าง):

if ( foo.equals("bar") ) {
 // ...
}

จะส่งผลให้NullPointerExceptionถ้าfooไม่มี

คุณสามารถหลีกเลี่ยงได้ถ้าคุณเปรียบเทียบStringแบบนี้:

if ( "bar".equals(foo) ) {
 // ...
}

ด้วย Java 8 มาใหม่ java.util.Optionalคลาสที่สามารถแก้ไขปัญหาบางอย่างได้ อย่างน้อยก็สามารถพูดได้ว่ามันช่วยปรับปรุงการอ่านรหัสและในกรณีของ API สาธารณะทำให้สัญญาของ API ชัดเจนขึ้นสำหรับนักพัฒนาไคลเอ็นต์

พวกเขาทำงานอย่างนั้น:

วัตถุทางเลือกสำหรับประเภทที่กำหนด ( Fruit) ถูกสร้างเป็นประเภทส่งคืนของวิธีการ มันอาจจะว่างเปล่าหรือมีFruitวัตถุ:

public static Optional<Fruit> find(String name, List<Fruit> fruits) {
   for (Fruit fruit : fruits) {
      if (fruit.getName().equals(name)) {
         return Optional.of(fruit);
      }
   }
   return Optional.empty();
}

ตอนนี้ดูรหัสนี้ที่เราค้นหารายการของFruit( fruits) สำหรับตัวอย่างผลไม้ที่กำหนด:

Optional<Fruit> found = find("lemon", fruits);
if (found.isPresent()) {
   Fruit fruit = found.get();
   String name = fruit.getName();
}

คุณสามารถใช้map()โอเปอเรเตอร์เพื่อทำการคำนวณ - หรือแยกค่าจาก - วัตถุทางเลือก orElse()ให้คุณจัดเตรียมทางเลือกสำหรับค่าที่หายไป

String nameOrNull = find("lemon", fruits)
    .map(f -> f.getName())
    .orElse("empty-name");

แน่นอนว่าการตรวจสอบค่าว่าง / ไม่ว่างยังเป็นสิ่งจำเป็น แต่อย่างน้อยผู้พัฒนาก็ตระหนักว่าค่าอาจว่างเปล่าและความเสี่ยงในการลืมตรวจสอบนั้นมี จำกัด

ใน API ที่สร้างขึ้นจากศูนย์โดยใช้Optionalเมื่อใดก็ตามที่ค่าส่งคืนอาจว่างเปล่าและส่งคืนวัตถุธรรมดาเฉพาะเมื่อไม่สามารถnull(แบบแผน) รหัสลูกค้าอาจละทิ้งการตรวจสอบค่า Null ของค่าส่งคืนวัตถุอย่างง่าย ...

แน่นอนว่าOptionalสามารถใช้เป็นอาร์กิวเมนต์เมธอดได้ซึ่งอาจเป็นวิธีที่ดีกว่าในการระบุอาร์กิวเมนต์เพิ่มเติมมากกว่า 5 หรือ 10 วิธีการโอเวอร์โหลดในบางกรณี

Optionalข้อเสนอวิธีการอื่น ๆ ที่สะดวกเช่นorElseที่อนุญาตให้ใช้ค่าเริ่มต้นและifPresentการทำงานที่มีการแสดงออกแลมบ์ดา

ผมขอเชิญคุณอ่านบทความนี้ (แหล่งที่มาหลักของการเขียนคำตอบนี้) ซึ่งในNullPointerException(และในชี้โมฆะทั่วไป) ที่มีปัญหาเช่นเดียวกับ (บางส่วน) วิธีการแก้ปัญหาโดยนำOptionalเป็นอย่างดีอธิบาย: Java ตัวเลือกวัตถุ

ขึ้นอยู่กับชนิดของวัตถุที่คุณกำลังตรวจสอบคุณอาจสามารถใช้บางคลาสใน apache คอมมอนส์เช่น: apache คอมมอนส์ langและapache คอมมอนส์คอลเลกชัน

ตัวอย่าง:

String foo;
...
if( StringUtils.isBlank( foo ) ) {
   ///do something
}

หรือ (ขึ้นอยู่กับสิ่งที่คุณต้องตรวจสอบ):

String foo;
...
if( StringUtils.isEmpty( foo ) ) {
   ///do something
}

คลาส StringUtils เป็นหนึ่งเดียวเท่านั้น มีคลาสที่ค่อนข้างดีอยู่ในคอมมอนส์ที่ทำการจัดการอย่างปลอดภัยเป็นโมฆะ

ต่อไปนี้เป็นตัวอย่างของวิธีการใช้ null vallidation ใน JAVA เมื่อคุณรวมไลบรารี apache (commons-lang-2.4.jar)

public DOCUMENT read(String xml, ValidationEventHandler validationEventHandler) {
    Validate.notNull(validationEventHandler,"ValidationHandler not Injected");
    return read(new StringReader(xml), true, validationEventHandler);
}

และถ้าคุณใช้ Spring, Spring ก็มีฟังก์ชั่นเดียวกันในแพ็คเกจดูที่ library (spring-2.4.6.jar)

ตัวอย่างเกี่ยวกับวิธีใช้ classf แบบคงที่นี้จากฤดูใบไม้ผลิ (org.springframework.util.Assert)

Assert.notNull(validationEventHandler,"ValidationHandler not Injected");

• หากคุณพิจารณาว่าวัตถุไม่ควรเป็นโมฆะ (หรือเป็นข้อผิดพลาด) ให้ใช้การยืนยัน
• หากวิธีการของคุณไม่ยอมรับ params โมฆะบอกว่ามันอยู่ใน javadoc และใช้การยืนยัน

คุณต้องตรวจสอบวัตถุ! = null เฉพาะในกรณีที่คุณต้องการจัดการกับกรณีที่วัตถุอาจเป็นโมฆะ ...

มีข้อเสนอที่จะเพิ่มคำอธิบายประกอบใหม่ใน Java7 เพื่อช่วยในการ null / notnull params: http://tech.puredanger.com/java7/#jsr308

ฉันเป็นแฟนของรหัส "ล้มเหลวอย่างรวดเร็ว" ถามตัวคุณเอง - คุณกำลังทำสิ่งที่มีประโยชน์ในกรณีที่พารามิเตอร์เป็นโมฆะหรือไม่ หากคุณไม่มีคำตอบที่ชัดเจนสำหรับสิ่งที่รหัสของคุณควรทำในกรณีนี้ ... นั่นคือไม่ควรเป็นโมฆะในตอนแรกให้เพิกเฉยและปล่อยให้ NullPointerException ถูกโยนทิ้ง รหัสการโทรจะทำให้มีความรู้สึกเหมือนกับ NPE เหมือนกับ IllegalArgumentException แต่จะง่ายขึ้นสำหรับนักพัฒนาที่จะทำการดีบักและเข้าใจว่าเกิดอะไรขึ้นถ้า NPE ถูกโยนแทนที่จะเป็นรหัสของคุณที่พยายามดำเนินการบางอย่างที่ไม่คาดคิดอื่น ๆ ตรรกะ - ซึ่งส่งผลให้แอปพลิเคชันล้มเหลวในที่สุด

เฟรมเวิร์กคอลเล็กชันของ Google นำเสนอวิธีที่ดีและสง่างามในการตรวจสอบ null

มีวิธีการในชั้นเรียนห้องสมุดเช่นนี้:

static <T> T checkNotNull(T e) {
   if (e == null) {
      throw new NullPointerException();
   }
   return e;
}

และการใช้งาน (ด้วยimport static):

...
void foo(int a, Person p) {
   if (checkNotNull(p).getAge() > a) {
      ...
   }
   else {
      ...
   }
}
...

หรือในตัวอย่างของคุณ:

checkNotNull(someobject).doCalc();

บางครั้งคุณมีวิธีการที่ใช้กับพารามิเตอร์ที่กำหนดการดำเนินการแบบสมมาตร:

a.f(b); <-> b.f(a);

ถ้าคุณรู้ว่าขไม่มีทางเป็นโมฆะคุณสามารถสลับมันได้ มันจะมีประโยชน์มากที่สุดสำหรับเท่ากับ: แทนที่จะดีกว่าทำfoo.equals("bar");"bar".equals(foo);

แทนที่จะใช้รูปแบบวัตถุ Null ซึ่งมีประโยชน์ - คุณอาจพิจารณาสถานการณ์ที่วัตถุ null เป็นจุดบกพร่อง

เมื่อข้อยกเว้นถูกส่งไปตรวจสอบการติดตามสแต็กและทำงานผ่านบั๊ก

Null ไม่ใช่ 'ปัญหา' มันเป็นส่วนสำคัญของชุดเครื่องมือสร้างแบบจำลองที่สมบูรณ์ ซอฟต์แวร์มีจุดมุ่งหมายเพื่อสร้างแบบจำลองความซับซ้อนของโลกและเป็นศูนย์รับภาระ Null ระบุว่า 'ไม่มีข้อมูล' หรือ 'ไม่รู้จัก'ใน Java และสิ่งที่คล้ายกัน ดังนั้นจึงเหมาะสมที่จะใช้ค่า Null เพื่อวัตถุประสงค์เหล่านี้ ฉันไม่ชอบรูปแบบ 'Null object' ฉันคิดว่ามันทำให้เกิด ' ผู้ที่จะปกป้องผู้พิทักษ์ '
หากคุณถามฉันชื่อแฟนของฉันคืออะไรฉันจะบอกคุณว่าฉันไม่มีแฟน ในภาษาจาวาฉันจะคืนค่า null อีกทางเลือกหนึ่งคือการโยนข้อยกเว้นที่มีความหมายเพื่อระบุปัญหาที่ไม่สามารถ (หรือไม่ ')

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

   public Photo getPhotoOfThePerson(Person person) {
       if (person == null)
           return null;
       // Grabbing some resources or intensive calculation
       // using person object anyhow.
   }

   ก่อนหน้านี้นำไปสู่การไหลของลอจิกปกติเพื่อไม่ให้มีภาพของแฟนสาวที่ไม่มีอยู่จริงจากห้องสมุดภาพถ่ายของฉัน

   getPhotoOfThePerson(me.getGirlfriend())

   และเหมาะกับ Java API ใหม่ (รอคอย)

   getPhotoByName(me.getGirlfriend()?.getName())

   ในขณะที่มันค่อนข้างเป็น 'การดำเนินธุรกิจปกติ' ไม่พบรูปภาพที่เก็บไว้ในฐานข้อมูลสำหรับบางคนฉันเคยใช้คู่เช่นด้านล่างสำหรับกรณีอื่น ๆ

   public static MyEnum parseMyEnum(String value); // throws IllegalArgumentException
   public static MyEnum parseMyEnumOrNull(String value);

   และอย่าเกลียดที่จะพิมพ์<alt> + <shift> + <j>(สร้าง javadoc ใน Eclipse) และเขียนคำเพิ่มเติมสามคำสำหรับ API สาธารณะของคุณ สิ่งนี้จะเพียงพอสำหรับทุกคนยกเว้นผู้ที่ไม่ได้อ่านเอกสาร

   /**
    * @return photo or null
    */

   หรือ

   /**
    * @return photo, never null
    */

2. นี้ค่อนข้างกรณีทฤษฎีและในกรณีส่วนใหญ่คุณควรต้องการ Java API null ปลอดภัย (ในกรณีที่มันจะได้รับการปล่อยตัวในอีก 10 ปี) แต่เป็นคลาสย่อยของNullPointerException Exceptionดังนั้นจึงเป็นรูปแบบThrowableที่บ่งบอกถึงเงื่อนไขว่าแอปพลิเคชันที่สมเหตุสมผลอาจต้องการที่จะจับ ( javadoc )! ในการใช้ประโยชน์แรกมากที่สุดของข้อยกเว้นและแยกต่างหากจัดการข้อผิดพลาดรหัสจากโค้ด 'ปกติ' ( ตามที่ผู้สร้างของ Java ) NullPointerExceptionมันมีความเหมาะสมเป็นสำหรับฉันที่จะจับ

   public Photo getGirlfriendPhoto() {
       try {
           return appContext.getPhotoDataSource().getPhotoByName(me.getGirlfriend().getName());
       } catch (NullPointerException e) {
           return null;
       }
   }

   คำถามอาจเกิดขึ้น:

   Q. จะเกิดอะไรขึ้นถ้าgetPhotoDataSource()ส่งคืน null
   A. มันขึ้นอยู่กับตรรกะทางธุรกิจ หากฉันไม่พบอัลบั้มรูปฉันจะไม่แสดงรูปให้คุณเห็น จะเกิดอะไรขึ้นถ้า appContext ไม่เริ่มต้น ตรรกะทางธุรกิจของวิธีการนี้สอดคล้องกับสิ่งนี้ หากตรรกะเดียวกันควรเข้มงวดมากขึ้นให้ส่งข้อยกเว้นเป็นส่วนหนึ่งของตรรกะทางธุรกิจและควรใช้การตรวจสอบความว่างเปล่า (กรณีที่ 3) ใหม่ Java Null ปลอดภัยเหมาะกับ API ที่ดีกว่าที่นี่เพื่อระบุการคัดเลือกสิ่งที่หมายถึงและสิ่งที่ไม่ได้หมายความว่าจะต้องเริ่มต้นที่จะล้มเหลวได้อย่างรวดเร็วในกรณีของข้อผิดพลาดโปรแกรมเมอร์

   Q. สามารถเรียกใช้รหัสซ้ำซ้อนและสามารถคว้าทรัพยากรที่ไม่จำเป็นออกได้
   ตอบอาจเกิดขึ้นได้หากgetPhotoByName()พยายามเปิดการเชื่อมต่อฐานข้อมูลสร้างPreparedStatementและใช้ชื่อบุคคลเป็นพารามิเตอร์ SQL ในที่สุด วิธีการสำหรับคำถามที่ไม่รู้จักให้คำตอบที่ไม่รู้จัก (กรณีที่ 1) ทำงานที่นี่ ก่อนที่จะทำการรวบรวมทรัพยากรวิธีควรตรวจสอบพารามิเตอร์และส่งคืนผลลัพธ์ 'ไม่ทราบ' หากจำเป็น

   ถามวิธีการนี้มีโทษประสิทธิภาพเนื่องจากมีการเปิดปิดทดลอง
   A. ซอฟต์แวร์ควรเข้าใจและแก้ไขได้ง่ายในตอนแรก หลังจากนี้จะมีใครคิดถึงการแสดงและถ้าจำเป็น! และในกรณีที่จำเป็น! ( แหล่งที่มา ) และอื่น ๆ อีกมากมาย)

   PS วิธีนี้จะมีเหตุผลที่จะใช้เป็นรหัสการจัดการข้อผิดพลาดแยกต่างหากจากหลักการรหัส "ปกติ" มีเหตุผลที่จะใช้ในบางสถานที่ ลองพิจารณาตัวอย่างต่อไป:

   public SomeValue calculateSomeValueUsingSophisticatedLogic(Predicate predicate) {
       try {
           Result1 result1 = performSomeCalculation(predicate);
           Result2 result2 = performSomeOtherCalculation(result1.getSomeProperty());
           Result3 result3 = performThirdCalculation(result2.getSomeProperty());
           Result4 result4 = performLastCalculation(result3.getSomeProperty());
           return result4.getSomeProperty();
       } catch (NullPointerException e) {
           return null;
       }
   }
   
   public SomeValue calculateSomeValueUsingSophisticatedLogic(Predicate predicate) {
       SomeValue result = null;
       if (predicate != null) {
           Result1 result1 = performSomeCalculation(predicate);
           if (result1 != null && result1.getSomeProperty() != null) {
               Result2 result2 = performSomeOtherCalculation(result1.getSomeProperty());
               if (result2 != null && result2.getSomeProperty() != null) {
                   Result3 result3 = performThirdCalculation(result2.getSomeProperty());
                   if (result3 != null && result3.getSomeProperty() != null) {
                       Result4 result4 = performLastCalculation(result3.getSomeProperty());
                       if (result4 != null) {
                           result = result4.getSomeProperty();
                       }
                   }
               }
           }
       }
       return result;
   }

   PPS สำหรับผู้ที่ลงคะแนนอย่างรวดเร็ว (และไม่เร็วในการอ่านเอกสาร) ฉันอยากจะบอกว่าฉันไม่เคยพบข้อยกเว้นตัวชี้โมฆะ (NPE) ในชีวิตของฉัน แต่เป็นไปได้นี้ได้รับการออกแบบโดยเจตนาโดยผู้สร้าง Java เพราะ NPE เป็น subclass Exceptionของ เรามีแบบอย่างในประวัติศาสตร์ Java เมื่อไม่ได้ThreadDeathเป็นErrorเพราะมันเป็นข้อผิดพลาดของแอปพลิเคชัน แต่เพียงอย่างเดียวเพราะมันไม่ได้ตั้งใจที่จะถูกจับ! NPE เหมาะกับการเป็นErrorมากกว่าเท่าไหร่ThreadDeath! แต่มันไม่ใช่

3. ตรวจสอบ 'ไม่มีข้อมูล' หากตรรกะทางธุรกิจบอกเป็นนัย

   public void updatePersonPhoneNumber(Long personId, String phoneNumber) {
       if (personId == null)
           return;
       DataSource dataSource = appContext.getStuffDataSource();
       Person person = dataSource.getPersonById(personId);
       if (person != null) {
           person.setPhoneNumber(phoneNumber);
           dataSource.updatePerson(person);
       } else {
           Person = new Person(personId);
           person.setPhoneNumber(phoneNumber);
           dataSource.insertPerson(person);
       }
   }

   และ

   public void updatePersonPhoneNumber(Long personId, String phoneNumber) {
       if (personId == null)
           return;
       DataSource dataSource = appContext.getStuffDataSource();
       Person person = dataSource.getPersonById(personId);
       if (person == null)
           throw new SomeReasonableUserException("What are you thinking about ???");
       person.setPhoneNumber(phoneNumber);
       dataSource.updatePerson(person);
   }

   หาก appContext หรือ dataSource ไม่ได้เริ่มต้นรันไทม์ที่ไม่ได้จัดการ NullPointerException จะฆ่าเธรดปัจจุบันและจะถูกประมวลผลโดยThread.defaultUncaughtExceptionHandler (สำหรับคุณในการกำหนดและใช้ตัวบันทึกรายการโปรด หากไม่ได้ตั้งค่าThreadGroup # uncaughtExceptionจะพิมพ์ stacktrace ไปที่ระบบ err หนึ่งควรตรวจสอบบันทึกข้อผิดพลาดของแอปพลิเคชันและเปิดปัญหา Jira สำหรับข้อยกเว้นที่ไม่ได้จัดการแต่ละอันซึ่งอันที่จริงแล้วคือข้อผิดพลาดของแอปพลิเคชัน โปรแกรมเมอร์ควรแก้ไขข้อผิดพลาดบางอย่างในสิ่งที่เริ่มต้น

Java 7 มีjava.util.Objectsคลาสยูทิลิตี้ใหม่ซึ่งมีrequireNonNull()วิธีการ ทั้งหมดนี้ก็คือการโยนNullPointerExceptionถ้าอาร์กิวเมนต์ของมันเป็นโมฆะ แต่มันทำความสะอาดโค้ดเล็กน้อย ตัวอย่าง:

Objects.requireNonNull(someObject);
someObject.doCalc();

วิธีนี้มีประโยชน์มากที่สุดสำหรับการตรวจสอบก่อนการกำหนดใน Constructor ซึ่งการใช้งานแต่ละครั้งสามารถบันทึกรหัสสามบรรทัด:

Parent(Child child) {
   if (child == null) {
      throw new NullPointerException("child");
   }
   this.child = child;
}

กลายเป็น

Parent(Child child) {
   this.child = Objects.requireNonNull(child, "child");
}

ในที่สุดวิธีเดียวที่จะแก้ปัญหานี้ได้อย่างสมบูรณ์คือการใช้ภาษาการเขียนโปรแกรมที่แตกต่างกัน:

• ใน Objective-C คุณสามารถทำสิ่งที่เทียบเท่ากับการเรียกใช้เมธอดnilและไม่มีอะไรเกิดขึ้นแน่นอน สิ่งนี้ทำให้การตรวจสอบโมฆะส่วนใหญ่ไม่จำเป็น แต่สามารถทำให้เกิดข้อผิดพลาดได้ยากขึ้นในการวินิจฉัย
• ในNiceภาษาที่ได้รับจาก Java มีทั้งหมดสองรุ่นคือรุ่นที่อาจเป็นโมฆะและรุ่นที่ไม่เป็นโมฆะ คุณสามารถเรียกใช้เมธอดในประเภทที่ไม่ใช่ค่าว่างเท่านั้น ประเภทที่อาจเป็นโมฆะสามารถแปลงเป็นประเภทที่ไม่เป็นโมฆะผ่านการตรวจสอบอย่างชัดเจนสำหรับโมฆะ สิ่งนี้ทำให้ง่ายต่อการทราบว่าการตรวจสอบค่าศูนย์เป็นสิ่งจำเป็นหรือไม่

"ปัญหา" ทั่วไปใน Java แน่นอน

ครั้งแรกที่ฉันคิดเกี่ยวกับเรื่องนี้:

ฉันคิดว่ามันไม่ดีที่จะ "กิน" บางสิ่งเมื่อ NULL ผ่านไปโดยที่ NULL ไม่ใช่ค่าที่ถูกต้อง หากคุณไม่ได้ออกจากวิธีการที่มีข้อผิดพลาดบางประเภทหมายความว่าไม่มีอะไรผิดพลาดในวิธีการของคุณซึ่งไม่เป็นความจริง จากนั้นคุณอาจกลับมาเป็นโมฆะในกรณีนี้และในวิธีการรับคุณตรวจสอบอีกครั้งเป็นโมฆะและมันไม่สิ้นสุดและคุณจะจบลงด้วย "if! = null" ฯลฯ

ดังนั้น IMHO, null จะต้องเป็นข้อผิดพลาดที่สำคัญซึ่งจะป้องกันไม่ให้มีการดำเนินการเพิ่มเติม (นั่นคือโดยที่ null ไม่ได้เป็นค่าที่ถูกต้อง)

วิธีที่ฉันแก้ปัญหานี้คือ:

ก่อนอื่นฉันปฏิบัติตามอนุสัญญานี้:

1. เมธอดสาธารณะทั้งหมด / API ตรวจสอบข้อโต้แย้งของตนว่าเป็นค่าว่างเสมอ
2. วิธีการส่วนตัวทั้งหมดไม่ตรวจสอบ null เนื่องจากเป็นวิธีการควบคุม (ให้ตายด้วยข้อยกเว้น nullpointer ในกรณีที่ไม่ได้จัดการด้านบน)
3. วิธีอื่น ๆ เท่านั้นที่ไม่ได้ตรวจสอบว่าเป็นโมฆะคือวิธีการอรรถประโยชน์ พวกเขาเป็นสาธารณะ แต่ถ้าคุณเรียกพวกเขาด้วยเหตุผลบางอย่างคุณรู้ว่าคุณผ่านพารามิเตอร์อะไร นี่เป็นเหมือนการพยายามต้มน้ำในกาต้มน้ำโดยไม่ให้น้ำ ...

และสุดท้ายในโค้ดบรรทัดแรกของวิธีสาธารณะจะเป็นดังนี้:

ValidationUtils.getNullValidator().addParam(plans, "plans").addParam(persons, "persons").validate();

โปรดทราบว่า addParam () คืนค่าตัวเองเพื่อให้คุณสามารถเพิ่มพารามิเตอร์เพิ่มเติมเพื่อตรวจสอบ

เมธอดvalidate()จะส่งการตรวจสอบValidationExceptionหากพารามิเตอร์ใด ๆ เป็นโมฆะ (ทำเครื่องหมายหรือไม่เลือกเป็นปัญหาด้านการออกแบบ / รสนิยมมากกว่า แต่ValidationExceptionมีการตรวจสอบแล้ว)

void validate() throws ValidationException;

ข้อความจะมีข้อความต่อไปนี้หากตัวอย่างเช่น "plans" เป็นโมฆะ:

" พบค่าอาร์กิวเมนต์ไม่ถูกต้องเป็นค่าว่างสำหรับพารามิเตอร์ [แผน] "

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

และใช่เรารู้ว่านอกเหนือจากบรรทัดนี้เราจะไม่พบค่าว่างอีกต่อไปดังนั้นเราจึงเรียกใช้วิธีการอย่างปลอดภัยกับวัตถุเหล่านั้น

วิธีนี้รหัสจะสะอาดง่ายต่อการดูแลและอ่านได้

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

1. อนุญาตให้ข้อยกเว้นกระเพื่อม - จับพวกมันที่ 'ลูปหลัก' หรือในรูทีนการจัดการอื่น ๆ

   • ตรวจสอบเงื่อนไขข้อผิดพลาดและจัดการอย่างเหมาะสม

แน่นอนว่าจะต้องดูที่การเขียนโปรแกรม Aspect Oriented ด้วย - พวกเขามีวิธีที่เรียบร้อยในการแทรกif( o == null ) handleNull()ลงในไบต์ของคุณ

นอกเหนือจากการใช้assertคุณสามารถใช้สิ่งต่อไปนี้:

if (someobject == null) {
    // Handle null here then move on.
}

นี่เป็นสิ่งที่ดีกว่า:

if (someobject != null) {
    .....
    .....



    .....
}

ไม่ใช้ null เลย ไม่อนุญาต

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

เมื่อฉันใช้การฝึกฝนนี้ฉันสังเกตว่าปัญหาดูเหมือนจะแก้ไขได้เอง คุณจะจับสิ่งต่าง ๆ ได้เร็วขึ้นในกระบวนการพัฒนาโดยไม่ได้ตั้งใจและตระหนักว่าคุณมีจุดอ่อน .. และที่สำคัญ .. มันช่วยสรุปความกังวลของโมดูลต่าง ๆ โมดูลต่าง ๆ สามารถ 'เชื่อใจ' ซึ่งกันและกันและไม่ทิ้งขยะ รหัสด้วยการif = null elseสร้าง!

นี่คือการตั้งโปรแกรมป้องกันและส่งผลให้รหัสที่ชัดเจนมากขึ้นในระยะยาว ฆ่าเชื้อโรคข้อมูลเช่นที่นี่โดยการบังคับใช้มาตรฐานที่เข้มงวดและปัญหาหายไป

class C {
    private final MyType mustBeSet;
    public C(MyType mything) {
       mustBeSet=Contract.notNull(mything);
    }
   private String name = "<unknown>";
   public void setName(String s) {
      name = Contract.notNull(s);
   }
}


class Contract {
    public static <T> T notNull(T t) { if (t == null) { throw new ContractException("argument must be non-null"); return t; }
}

สัญญาเป็นเหมือนการทดสอบหน่วยขนาดเล็กที่ทำงานอยู่เสมอแม้ในการผลิตและเมื่อสิ่งต่าง ๆ ล้มเหลวคุณรู้ว่าทำไมแทนที่จะเป็น NPE แบบสุ่มคุณต้องหาวิธีใด ๆ

Guava ห้องสมุดแกนที่มีประโยชน์มากโดย Google มี API ที่ดีและมีประโยชน์เพื่อหลีกเลี่ยงค่าว่าง ฉันพบว่าUsingAndAvoidingNull อธิบายมีประโยชน์มาก

ตามที่อธิบายไว้ในวิกิ:

Optional<T>เป็นวิธีในการแทนที่การอ้างอิง T nullable ด้วยค่าที่ไม่เป็นโมฆะ ตัวเลือกอาจประกอบด้วยการอ้างอิง T ที่ไม่เป็นโมฆะ (ในกรณีที่เราบอกว่าการอ้างอิงคือ "ปัจจุบัน") หรืออาจไม่มีอะไรเลย (ในกรณีนี้เราบอกว่าการอ้างอิงนั้นเป็น "ขาด") มันไม่เคยบอกว่า "มีค่าว่าง"

การใช้งาน:

Optional<Integer> possible = Optional.of(5);
possible.isPresent(); // returns true
possible.get(); // returns 5

นี่เป็นปัญหาที่พบบ่อยมากสำหรับนักพัฒนา Java ทุกคน ดังนั้นจึงมีการสนับสนุนอย่างเป็นทางการใน Java 8 เพื่อแก้ไขปัญหาเหล

Java 8 java.util.Optional<T>ได้แนะนำ มันเป็นภาชนะที่อาจหรือไม่อาจเก็บค่าที่ไม่ใช่ศูนย์ Java 8 ได้ให้วิธีที่ปลอดภัยกว่าในการจัดการกับวัตถุที่มีค่าอาจเป็นโมฆะในบางกรณี มันเป็นแรงบันดาลใจจากความคิดของHaskellและสกาล่า

โดยสรุปคลาสทางเลือกมีวิธีการจัดการกรณีและปัญหาที่มีค่าอยู่หรือขาดหายไปอย่างชัดเจน อย่างไรก็ตามข้อดีเมื่อเทียบกับการอ้างอิงว่างคือคลาสตัวเลือก <T> บังคับให้คุณคิดถึงกรณีและปัญหาเมื่อไม่มีค่า ดังนั้นคุณสามารถป้องกันข้อยกเว้นตัวชี้โมฆะที่ไม่ได้ตั้งใจได้

ในตัวอย่างข้างต้นเรามีโรงงานบริการที่บ้านซึ่งส่งคืนการจัดการไปยังอุปกรณ์หลายเครื่องที่มีอยู่ในบ้าน แต่บริการเหล่านี้อาจมีหรือไม่มีให้ใช้งาน มันหมายความว่ามันอาจส่งผลให้ NullPointerException แทนการเพิ่มifเงื่อนไขที่เป็นโมฆะก่อนที่จะใช้บริการใด ๆ ลองห่อในตัวเลือก <Service>

เปลี่ยนเป็นตัวเลือก <T>

ลองพิจารณาวิธีรับการอ้างอิงบริการจากโรงงาน แทนที่จะส่งคืนการอ้างอิงบริการห่อด้วยตัวเลือก ช่วยให้ผู้ใช้ API ทราบว่าบริการที่ส่งคืนอาจมีหรือไม่มีให้ใช้งานหรือใช้งานได้

public Optional<Service> getRefrigertorControl() {
      Service s = new  RefrigeratorService();
       //...
      return Optional.ofNullable(s);
   }

ตามที่คุณเห็นOptional.ofNullable()ให้วิธีง่ายๆในการรับการอ้างอิงแบบห่อ มีวิธีการที่จะได้รับการอ้างอิงของตัวเลือกอื่นเป็นอย่างใดอย่างหนึ่งและOptional.empty() Optional.of()อันที่หนึ่งสำหรับการคืนค่าวัตถุว่างเปล่าแทนการปรับค่า Null และค่าอื่น ๆ เพื่อตัดค่าวัตถุที่ไม่เป็นค่าว่างตามลำดับ

มันจะช่วยให้หลีกเลี่ยงการตรวจสอบค่า NULL ได้อย่างไร?

เมื่อคุณห่อวัตถุอ้างอิงแล้วทางเลือกจะมีวิธีการที่มีประโยชน์มากมายให้เรียกใช้วิธีการอ้างอิงแบบห่อโดยไม่มี NPE

Optional ref = homeServices.getRefrigertorControl();
ref.ifPresent(HomeServices::switchItOn);

ไม่บังคับ. ifPresent จะเรียกใช้ Consumer ที่ระบุพร้อมกับการอ้างอิงหากเป็นค่าที่ไม่ใช่ค่า null มิฉะนั้นจะไม่ทำอะไรเลย

@FunctionalInterface
public interface Consumer<T>

แสดงให้เห็นถึงการดำเนินงานที่รับอาร์กิวเมนต์อินพุตเดียวและส่งกลับไม่มีผล แตกต่างจากอินเทอร์เฟซการทำงานอื่น ๆ ส่วนใหญ่ Consumer คาดว่าจะทำงานผ่านผลข้างเคียง มันสะอาดและง่ายต่อการเข้าใจ ในตัวอย่างโค้ดข้างต้นHomeService.switchOn(Service)ได้รับการเรียกถ้าการอ้างอิงการถือครองไม่จำเป็นเป็นโมฆะ

เราใช้ผู้ประกอบการที่สามบ่อยมากสำหรับการตรวจสอบสภาพเป็นโมฆะและส่งกลับค่าทางเลือกหรือค่าเริ่มต้น ทางเลือกเป็นอีกวิธีหนึ่งในการจัดการสภาพเดียวกันโดยไม่ตรวจสอบค่าว่าง ไม่บังคับ. orElse (defaultObj) จะส่งกลับ defaultObj หากตัวเลือกมีค่า Null ลองใช้สิ่งนี้ในโค้ดตัวอย่างของเรา:

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

ตอนนี้ HomeServices.get () ทำสิ่งเดียวกัน แต่เป็นวิธีที่ดีกว่า มันจะตรวจสอบว่าบริการได้เริ่มต้นแล้วไม่ หากเป็นเช่นนั้นให้ส่งคืนหรือสร้างบริการใหม่ ตัวเลือก <T> .orElse (T) ช่วยในการส่งคืนค่าเริ่มต้น

สุดท้ายนี่คือ NPE ของเราเช่นเดียวกับรหัสการตรวจสอบที่ว่างเปล่า:

import java.util.Optional;
public class HomeServices {
    private static final int NOW = 0;
    private static Optional<HomeServices> service;

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

public Optional<Service> getRefrigertorControl() {
    Service s = new  RefrigeratorService();
    //...
    return Optional.ofNullable(s);
}

public static void main(String[] args) {
    /* Get Home Services handle */
    Optional<HomeServices> homeServices = HomeServices.get();
    if(homeServices != null) {
        Optional<Service> refrigertorControl = homeServices.get().getRefrigertorControl();
        refrigertorControl.ifPresent(HomeServices::switchItOn);
    }
}

public static void switchItOn(Service s){
         //...
    }
}

โพสต์ที่สมบูรณ์คือNPE เช่นเดียวกับรหัสตรวจสอบฟรี Null …จริงเหรอ? .

ฉันชอบบทความจาก Nat Pryce นี่คือลิงค์:

• หลีกเลี่ยง Nulls ด้วย Polymorphic Dispatch
• หลีกเลี่ยง Nulls ด้วยสไตล์ "บอกอย่าถาม"

ในบทความยังมีลิงค์ไปยังที่เก็บ Git สำหรับ Java บางที Type ที่ฉันสนใจ แต่ฉันไม่คิดว่ามันคนเดียวสามารถลดการขยายตัวของรหัสตรวจสอบได้ หลังจากทำการค้นคว้าบนอินเทอร์เน็ตฉันคิดว่า! = null code bloat อาจลดลงได้ส่วนใหญ่จากการออกแบบอย่างระมัดระวัง

ฉันได้ลองแล้วNullObjectPatternแต่สำหรับฉันไม่ได้เป็นวิธีที่ดีที่สุดเสมอไป บางครั้งมีเมื่อ "ไม่มีการกระทำ" ไม่เหมาะสม

NullPointerExceptionเป็นข้อยกเว้น Runtimeซึ่งหมายถึงว่าเป็นความผิดของนักพัฒนาและมีประสบการณ์เพียงพอที่จะบอกคุณได้อย่างแม่นยำว่าข้อผิดพลาดนั้นอยู่ที่ไหน

ตอนนี้ถึงคำตอบ:

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

แน่นอนว่าประสบการณ์เป็นวิธีที่ดีกว่าในการทำความเข้าใจและใช้คำแนะนำนี้

Byte!

อาจเป็นทางเลือกที่ดีที่สุดสำหรับ Java 8 หรือใหม่กว่าคือการใช้Optionalคลาส

Optional stringToUse = Optional.of("optional is there");
stringToUse.ifPresent(System.out::println);

สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับโซ่ยาวที่มีค่า Null เป็นไปได้ ตัวอย่าง:

Optional<Integer> i = Optional.ofNullable(wsObject.getFoo())
    .map(f -> f.getBar())
    .map(b -> b.getBaz())
    .map(b -> b.getInt());

ตัวอย่างวิธีโยนข้อยกเว้นบน null:

Optional optionalCarNull = Optional.ofNullable(someNull);
optionalCarNull.orElseThrow(IllegalStateException::new);

Java 7 แนะนำObjects.requireNonNullวิธีการที่จะมีประโยชน์เมื่อมีการตรวจสอบสิ่งที่ไม่ใช่ความว่างเปล่า ตัวอย่าง:

String lowerVal = Objects.requireNonNull(someVar, "input cannot be null or empty").toLowerCase();

ฉันขอตอบโดยทั่วไปมากกว่านี้ได้ไหม!

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

ดังนั้นจึงไม่มีความแตกต่างระหว่าง:

if(object == null){
   //you called my method badly!

}

หรือ

if(str.length() == 0){
   //you called my method badly again!
}

พวกเขาทั้งสองต้องการตรวจสอบให้แน่ใจว่าเราได้รับพารามิเตอร์ที่ถูกต้องก่อนที่เราจะทำหน้าที่อื่น ๆ

ดังที่กล่าวไว้ในคำตอบอื่น ๆ เพื่อหลีกเลี่ยงปัญหาข้างต้นคุณสามารถทำตามรูปแบบสัญญา โปรดดูhttp://en.wikipedia.org/wiki/Design_by_contract

ที่จะใช้รูปแบบนี้ใน java คุณสามารถใช้คำอธิบายประกอบจาวาหลักเช่นjavax.annotation.NotNullหรือใช้ห้องสมุดที่มีความซับซ้อนมากขึ้นเช่นHibernate ตรวจสอบ

เพียงตัวอย่าง:

getCustomerAccounts(@NotEmpty String customerId,@Size(min = 1) String accountType)

ตอนนี้คุณสามารถพัฒนาฟังก์ชั่นหลักของวิธีการของคุณได้อย่างปลอดภัยโดยไม่จำเป็นต้องตรวจสอบพารามิเตอร์อินพุตพวกเขาป้องกันวิธีการของคุณจากพารามิเตอร์ที่ไม่คาดคิด

คุณสามารถไปอีกขั้นหนึ่งและตรวจสอบให้แน่ใจว่าสามารถสร้าง pojos ที่ถูกต้องเท่านั้นในแอปพลิเคชันของคุณ (ตัวอย่างจากไซต์เครื่องมือตรวจสอบไฮเบอร์เนต)

public class Car {

   @NotNull
   private String manufacturer;

   @NotNull
   @Size(min = 2, max = 14)
   private String licensePlate;

   @Min(2)
   private int seatCount;

   // ...
}

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

ในความเป็นจริงหากสิ่งที่ส่งคืนจากวิธีการเป็นโมฆะและรหัสการโทรต้องตัดสินใจตามนั้นควรมีการโทรก่อนหน้านี้ที่ช่วยให้มั่นใจรัฐ

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

นอกจากนี้ฉันจะไม่แนะนำให้ใช้รูปแบบนี้ซึ่งประเภทนี้หมายถึงการเป็นตัวแทนประเภทดั้งเดิม - เช่นเอนทิตีทางคณิตศาสตร์ที่ไม่ใช่ scalars: เวกเตอร์, เมทริกซ์, จำนวนเชิงซ้อนและวัตถุ POD (ข้อมูลเก่าแบบธรรมดา) ซึ่งหมายถึงการรักษาสถานะ ในรูปแบบของ Java ชนิดในตัว ในกรณีหลังคุณจะสิ้นสุดการเรียกวิธีการทะเยอทะยานกับผลลัพธ์โดยพลการ ตัวอย่างเช่นเมธอด NullPerson.getName () ควรส่งคืนอย่างไร

ควรพิจารณากรณีดังกล่าวเพื่อหลีกเลี่ยงผลลัพธ์ที่ไร้สาระ

1. อย่าเริ่มต้นตัวแปรเป็นโมฆะ
2. ถ้าเป็นไปไม่ได้ (1) ให้เริ่มต้นการรวบรวมและอาร์เรย์ทั้งหมดเพื่อทำการรวบรวม / อาร์เรย์ว่าง

การทำเช่นนี้ในรหัสของคุณเองและคุณสามารถหลีกเลี่ยง! = null ตรวจสอบ

การตรวจสอบโมฆะเวลาส่วนใหญ่ดูเหมือนจะป้องกันการวนรอบคอลเลกชันหรืออาร์เรย์ดังนั้นเพียงกำหนดค่าเริ่มต้นให้ว่างคุณไม่จำเป็นต้องตรวจสอบ null

// Bad
ArrayList<String> lemmings;
String[] names;

void checkLemmings() {
    if (lemmings != null) for(lemming: lemmings) {
        // do something
    }
}



// Good
ArrayList<String> lemmings = new ArrayList<String>();
String[] names = {};

void checkLemmings() {
    for(lemming: lemmings) {
        // do something
    }
}

มีค่าใช้จ่ายเล็กน้อยในเรื่องนี้ แต่มันคุ้มค่าสำหรับโค้ดที่สะอาดกว่าและ NullPointerExceptions ที่น้อยลง

นี่เป็นข้อผิดพลาดทั่วไปที่เกิดขึ้นกับนักพัฒนาส่วนใหญ่

เรามีหลายวิธีในการจัดการกับสิ่งนี้

วิธีที่ 1:

org.apache.commons.lang.Validate //using apache framework

notNull (วัตถุวัตถุข้อความสตริง)

วิธีที่ 2:

if(someObject!=null){ // simply checking against null
}

วิธีที่ 3:

@isNull @Nullable  // using annotation based validation

วิธีที่ 4:

// by writing static method and calling it across whereever we needed to check the validation

static <T> T isNull(someObject e){  
   if(e == null){
      throw new NullPointerException();
   }
   return e;
}

public static <T> T ifNull(T toCheck, T ifNull) {
    if (toCheck == null) {
           return ifNull;
    }
    return toCheck;
}