Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

JVM Languages

Bug Opportunity Levels

Level 2: If there is a bug, it will result in a runtime error describing the problem. This case is worse than the previous one in a couple of ways.

  • First, it takes more steps to discover a bug. The cycle of edit-compile must be lengthened to edit-compile-run-test. This will slow down your debugging quite a bit.
  • Second, a bug may be in a piece of code that does not get executed every time the program is run, or it may only occur under special circumstances. A lot of testing could be required before it is discovered, and even then, it is hard to be confident that all bugs have been found.

This is the reason that languages with static typechecking, such as Java, are generally preferred when writing large applications. In a dynamically typed language such as Python or Ruby, you can invoke any method on any object. The compiler does not know what type of object is stored in any variable, and just trusts that it has a method with the specified name that takes the right set of arguments. If this assumption is wrong, the result is a runtime error.

To be fair, this can be a very useful tool in certain cases. It also allows your source code to be slightly more concise, which is convenient when writing simple scripts. But for large applications, those benefits are far outweighed by the lack of compile-time error checking. This is one of the reasons that so many more applications are written in Java than in Python.

A level 2 bug opportunity is definitely worse than a level 1, but it is still not that bad. If all bugs were of this sort, debugging would be a relatively simple and painless process. Now let's consider a case that really is bad.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.