2013-04-18 56 views
7

Trong khi hoạt động số học Java, JVM không ném Ngoại lệ tràn hoặc tràn. Vì vậy, nhiều lần chúng tôi đi qua kết quả bất ngờ và tự hỏi những gì đã đi sai.Tại sao, trong số học Java, tràn hoặc tràn sẽ không bao giờ ném một ngoại lệ?

Trong trường hợp trong trường hợp công nghệ .NET, chúng tôi có ngoại lệ tràn và hoàn nguyên.

Vì vậy, câu hỏi của tôi là, tại sao Java là thiết kế không phải để ném ngoại lệ này trong hoạt động số học

+0

http://stackoverflow.com/questions/15998008/why-do-integer-datatypes-overflow-silently-rather-than-throwing-exception –

+0

Tài liệu đọc khác: http://stackoverflow.com/questions/103654/why-dont-languages-raise-errors-on-integer-overflow-by-default? rq = 1 –

Trả lời

6

Đây là có thể là một sự kết hợp của các yếu tố:

  1. Các ngôn ngữ lớn trước khi Java sử dụng số học không được kiểm soát. Thuật toán nổi tiếng dễ bị tràn số có xu hướng chiếm tài khoản cho tràn tiềm năng mà không dựa vào số học được kiểm tra.
  2. Số học được kiểm tra giới thiệu chi phí đáng kể trong các thuật toán sử dụng nhiều chỉ dẫn số học, điều này sẽ đưa Java vào một bất lợi đáng kể, đặc biệt là cho điểm chuẩn.
  3. Một số thuật toán dựa vào tràn/tràn số im lặng. Nếu các phép tính số học được kiểm tra, việc viết lại các thuật toán này có thể nhanh chóng trở thành không tầm thường.
  4. Số học được kiểm tra là không cần thiết để đảm bảo an toàn bộ nhớ (trái với các kiểm tra JVM khác như con trỏ null và giới hạn mảng).

Môi trường thực thi ảo .NET (bây giờ là một phần của tiêu chuẩn ECMA-335) đã giới thiệu các hướng dẫn riêng biệt cho kiểm tra và không kiểm tra, cho phép nó độc lập giải quyết các vấn đề về hiệu suất và an toàn của các nhà phát triển.

1

Khi Java ban đầu được tạo ra, các nhà thiết kế ngôn ngữ đã làm như vậy. Tôi không chắc chắn tại sao, nhưng nếu nó chắc chắn sẽ có một hình phạt hiệu suất trong việc nâng cao ngoại lệ.

"Bài học cho các nhà thiết kế ngôn ngữ là nó có thể có giá trị làm giảm khả năng của tràn im lặng. Điều này có thể được thực hiện bằng cách cung cấp hỗ trợ cho số học mà không tràn âm thầm. Chương có thể ném một ngoại lệ thay vì tràn , cũng như Ada, hoặc họ có thể chuyển sang một đại diện nội bộ lớn hơn tự động theo yêu cầu để tránh tràn, cũng như Lisp. Cả hai cách tiếp cận này đều có thể có các hình phạt về hiệu suất liên quan đến chúng. Một cách khác để giảm bớt khả năng bị tràn im lặng là để hỗ trợ nhập mục tiêu, nhưng điều này làm tăng thêm sự phức tạp đáng kể đối với hệ thống loại [Modula-3 1.4.8]. "

Courtesy - Java Puzzlers bẫy và cạm bẫy bởi Joshua Bloch & Neal Gafter

+0

Nhưng tôi vẫn thêm một số câu trả lời hữu ích. Tôi đánh giá cao bạn cho rằng, nhưng tôi không nghĩ rằng nó xứng đáng được bỏ phiếu xuống. – IndoKnight

+0

Bạn có thể cung cấp báo giá dài hơn từ sách không? –

+0

Không có vấn đề gì, được thêm vào câu trả lời của tôi :) – IndoKnight

2

Nó có lẽ đã làm với hiệu suất như Indoknight nói. Java cung cấp các công cụ để chăm sóc tràn, vì vậy nếu bạn cần phát hiện nó, bạn có thể làm điều đó. Bạn cũng có lâu dài và BigInteger và có thể sử dụng chúng để tránh tràn int của bạn.

Bạn sẽ thấy câu trả lời này từ một câu hỏi tương tự trong luồng ngăn xếp. How does Java handle integer underflows and overflows and how would you check for it?

+0

+1 cho thông tin liên quan. Cho dù đó là câu trả lời thực tế hay không nên được quyết định bởi OP Tôi nghĩ rằng phải trung thực :) – IndoKnight

1

Java dựa trên C và C++ dựa trên Assembly. Không có ngôn ngữ nào trong số này là ngoại lệ được ném, một phần vì Ngoại lệ không có trong các ngôn ngữ đó khi các phép toán số học được thiết kế.

Sẽ an toàn hơn khi sử dụng loại lớn hơn như long hoặc double hoặc BigInteger hoặc BigDecimal ngay từ đầu và chỉ sử dụng các loại nhỏ hơn nếu bạn thực sự chắc chắn điều này không phù hợp.

Nó không phải là một vấn đề phổ biến nếu bạn sử dụng các loại rộng hơn.

+3

Hội không đặt một lá cờ tràn khi một tràn được ném mặc dù. –

Các vấn đề liên quan