214 lines
12 KiB
Text
214 lines
12 KiB
Text
#
|
|
# AUTHOR <EMAIL@ADDRESS>, YEAR.
|
|
#
|
|
msgid ""
|
|
msgstr ""
|
|
"Project-Id-Version: 0\n"
|
|
"POT-Creation-Date: 2013-09-18T00:49:42\n"
|
|
"PO-Revision-Date: 2013-09-18T00:49:42\n"
|
|
"Last-Translator: Automatically generated\n"
|
|
"Language-Team: None\n"
|
|
"MIME-Version: 1.0\n"
|
|
"Content-Type: application/x-publican; charset=UTF-8\n"
|
|
"Content-Transfer-Encoding: 8bit\n"
|
|
|
|
#. Tag: title
|
|
#, no-c-format
|
|
msgid "The core language"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Implementations of the Java programming language provide strong memory safety, even in the presence of data races in concurrent code. This prevents a large range of security vulnerabilities from occurring, unless certain low-level features are used; see <xref linkend=\"sect-Defensive_Coding-Java-LowLevel\" />."
|
|
msgstr ""
|
|
|
|
#. Tag: title
|
|
#, no-c-format
|
|
msgid "Inceasing robustness when reading arrays"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "External data formats often include arrays, and the data is stored as an integer indicating the number of array elements, followed by this number of elements in the file or protocol data unit. This length specified can be much larger than what is actually available in the data source."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "To avoid allocating extremely large amounts of data, you can allocate a small array initially and grow it as you read more data, implementing an exponential growth policy. See the <function>readBytes(InputStream, int)</function> function in <xref linkend=\"ex-Defensive_Coding-Java-Language-ReadArray\" />."
|
|
msgstr ""
|
|
|
|
#. Tag: title
|
|
#, no-c-format
|
|
msgid "Incrementally reading a byte array"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "When reading data into arrays, hash maps or hash sets, use the default constructor and do not specify a size hint. You can simply add the elements to the collection as you read them."
|
|
msgstr ""
|
|
|
|
#. Tag: title
|
|
#, no-c-format
|
|
msgid "Resource management"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Unlike C++, Java does not offer destructors which can deallocate resources in a predictable fashion. All resource management has to be manual, at the usage site. (Finalizers are generally not usable for resource management, especially in high-performance code; see <xref linkend=\"sect-Defensive_Coding-Java-Language-Finalizers\" />.)"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "The first option is the <literal>try</literal>-<literal>finally</literal> construct, as shown in <xref linkend=\"ex-Defensive_Coding-Java-Language-Finally\" />. The code in the <literal>finally</literal> block should be as short as possible and should not throw any exceptions."
|
|
msgstr ""
|
|
|
|
#. Tag: title
|
|
#, no-c-format
|
|
msgid "Resource management with a <literal>try</literal>-<literal>finally</literal> block"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Note that the resource allocation happens <emphasis>outside</emphasis> the <literal>try</literal> block, and that there is no <literal>null</literal> check in the <literal>finally</literal> block. (Both are common artifacts stemming from IDE code templates.)"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "If the resource object is created freshly and implements the <literal>java.lang.AutoCloseable</literal> interface, the code in <xref linkend=\"ex-Defensive_Coding-Java-Language-TryWithResource\" /> can be used instead. The Java compiler will automatically insert the <function>close()</function> method call in a synthetic <literal>finally</literal> block."
|
|
msgstr ""
|
|
|
|
#. Tag: title
|
|
#, no-c-format
|
|
msgid "Resource management using the <literal>try</literal>-with-resource construct"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "To be compatible with the <literal>try</literal>-with-resource construct, new classes should name the resource deallocation method <function>close()</function>, and implement the <literal>AutoCloseable</literal> interface (the latter breaking backwards compatibility with Java 6). However, using the <literal>try</literal>-with-resource construct with objects that are not freshly allocated is at best awkward, and an explicit <literal>finally</literal> block is usually the better approach."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "In general, it is best to design the programming interface in such a way that resource deallocation methods like <function>close()</function> cannot throw any (checked or unchecked) exceptions, but this should not be a reason to ignore any actual error conditions."
|
|
msgstr ""
|
|
|
|
#. Tag: title
|
|
#, no-c-format
|
|
msgid "Finalizers"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Finalizers can be used a last-resort approach to free resources which would otherwise leak. Finalization is unpredictable, costly, and there can be a considerable delay between the last reference to an object going away and the execution of the finalizer. Generally, manual resource management is required; see <xref linkend=\"sect-Defensive_Coding-Java-Language-Resources\" />."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Finalizers should be very short and should only deallocate native or other external resources held directly by the object being finalized. In general, they must use synchronization: Finalization necessarily happens on a separate thread because it is inherently concurrent. There can be multiple finalization threads, and despite each object being finalized at most once, the finalizer must not assume that it has exclusive access to the object being finalized (in the <literal>this</literal> pointer)."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Finalizers should not deallocate resources held by other objects, especially if those objects have finalizers on their own. In particular, it is a very bad idea to define a finalizer just to invoke the resource deallocation method of another object, or overwrite some pointer fields."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Finalizers are not guaranteed to run at all. For instance, the virtual machine (or the machine underneath) might crash, preventing their execution."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Objects with finalizers are garbage-collected much later than objects without them, so using finalizers to zero out key material (to reduce its undecrypted lifetime in memory) may have the opposite effect, keeping objects around for much longer and prevent them from being overwritten in the normal course of program execution."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "For the same reason, code which allocates objects with finalizers at a high rate will eventually fail (likely with a <literal>java.lang.OutOfMemoryError</literal> exception) because the virtual machine has finite resources for keeping track of objects pending finalization. To deal with that, it may be necessary to recycle objects with finalizers."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "The remarks in this section apply to finalizers which are implemented by overriding the <function>finalize()</function> method, and to custom finalization using reference queues."
|
|
msgstr ""
|
|
|
|
#. Tag: title
|
|
#, no-c-format
|
|
msgid "Recovering from exceptions and errors"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Java exceptions come in three kinds, all ultimately deriving from <literal>java.lang.Throwable</literal>:"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "<emphasis>Run-time exceptions</emphasis> do not have to be declared explicitly and can be explicitly thrown from any code, by calling code which throws them, or by triggering an error condition at run time, like division by zero, or an attempt at an out-of-bounds array access. These exceptions derive from from the <literal>java.lang.RuntimeException</literal> class (perhaps indirectly)."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "<emphasis>Checked exceptions</emphasis> have to be declared explicitly by functions that throw or propagate them. They are similar to run-time exceptions in other regards, except that there is no language construct to throw them (except the <literal>throw</literal> statement itself). Checked exceptions are only present at the Java language level and are only enforced at compile time. At run time, the virtual machine does not know about them and permits throwing exceptions from any code. Checked exceptions must derive (perhaps indirectly) from the <literal>java.lang.Exception</literal> class, but not from <literal>java.lang.RuntimeException</literal>."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "<emphasis>Errors</emphasis> are exceptions which typically reflect serious error conditions. They can be thrown at any point in the program, and do not have to be declared (unlike checked exceptions). In general, it is not possible to recover from such errors; more on that below, in <xref linkend=\"sect-Defensive_Coding-Java-Language-Exceptions-Errors\" />. Error classes derive (perhaps indirectly) from <literal>java.lang.Error</literal>, or from <literal>java.lang.Throwable</literal>, but not from <literal>java.lang.Exception</literal>."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "The general expection is that run-time errors are avoided by careful programming (e.g., not dividing by zero). Checked exception are expected to be caught as they happen (e.g., when an input file is unexpectedly missing). Errors are impossible to predict and can happen at any point and reflect that something went wrong beyond all expectations."
|
|
msgstr ""
|
|
|
|
#. Tag: title
|
|
#, no-c-format
|
|
msgid "The difficulty of catching errors"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Errors (that is, exceptions which do not (indirectly) derive from <literal>java.lang.Exception</literal>), have the peculiar property that catching them is problematic. There are several reasons for this:"
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "The error reflects a failed consistenty check, for example, <literal>java.lang.AssertionError</literal>."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "The error can happen at any point, resulting in inconsistencies due to half-updated objects. Examples are <literal>java.lang.ThreadDeath</literal>, <literal>java.lang.OutOfMemoryError</literal> and <literal>java.lang.StackOverflowError</literal>."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "The error indicates that virtual machine failed to provide some semantic guarantees by the Java programming language. <literal>java.lang.ExceptionInInitializerError</literal> is an example—it can leave behind a half-initialized class."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "In general, if an error is thrown, the virtual machine should be restarted as soon as possible because it is in an inconsistent state. Continuing running as before can have unexpected consequences. However, there are legitimate reasons for catching errors because not doing so leads to even greater problems."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "Code should be written in a way that avoids triggering errors. See <xref linkend=\"sect-Defensive_Coding-Java-Language-ReadArray\" /> for an example."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "It is usually necessary to log errors. Otherwise, no trace of the problem might be left anywhere, making it very difficult to diagnose realted failures. Consequently, if you catch <literal>java.lang.Exception</literal> to log and suppress all unexpected exceptions (for example, in a request dispatching loop), you should consider switching to <literal>java.lang.Throwable</literal> instead, to also cover errors."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "The other reason mainly applies to such request dispatching loops: If you do not catch errors, the loop stops looping, resulting in a denial of service."
|
|
msgstr ""
|
|
|
|
#. Tag: para
|
|
#, no-c-format
|
|
msgid "However, if possible, catching errors should be coupled with a way to signal the requirement of a virtual machine restart."
|
|
msgstr ""
|
|
|