This file is indexed.

/usr/share/GNUstep/Documentation/Developer/CodingStandards/gs-standards/Error-Handling.html is in gnustep-base-doc 1.24.7-1build2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Created by GNU Texinfo 6.1, http://www.gnu.org/software/texinfo/ -->
<head>
<title>Coding Standards for GNUstep Libraries: Error Handling</title>

<meta name="description" content="Coding Standards for GNUstep Libraries: Error Handling">
<meta name="keywords" content="Coding Standards for GNUstep Libraries: Error Handling">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="index.html#Top" rel="start" title="Top">
<link href="index.html#Top" rel="up" title="Top">
<link href="Variable-Declaration.html#Variable-Declaration" rel="next" title="Variable Declaration">
<link href="Memory-Management.html#Memory-Management" rel="prev" title="Memory Management">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smalllisp {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: initial; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
ul.no-bullet {list-style: none}
-->
</style>


</head>

<body lang="en">
<a name="Error-Handling"></a>
<div class="header">
<p>
Next: <a href="Variable-Declaration.html#Variable-Declaration" accesskey="n" rel="next">Variable Declaration</a>, Previous: <a href="Memory-Management.html#Memory-Management" accesskey="p" rel="prev">Memory Management</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> &nbsp; </p>
</div>
<hr>
<a name="Error-Handling-1"></a>
<h2 class="chapter">6 Error Handling</h2>

<p>Initialisation methods (e.g. -init) should, upon failure to
initialise the class, release itself and return nil. This may mean
in certain cases, that it should catch exceptions, since the calling
method will be expecting a nil object rather than an exception on
failure. However, init methods should endeavour to provide some
information, via NSLog, on the failure.
</p>
<p>All other methods should cause an exception on failure*, unless
returning nil is a valid response (e.g. [dictionary
objectForKey: nil]) or if documented otherwise.
</p>
<p>Failure here is a relative term. I&rsquo;d interpret failure to occur when
either system resources have been exceeded, an operation was performed
on invalid data, or a required precondition was not met.
On the other hand, passing a nil object as a parameter (as in
[(NSMutableData *)data appendData: nil]), or other &quot;unusual&quot;
requests should succeed in a reasonable manner (or return nil, if
appropriate) and/or reasonable default values could be used.
</p>
<p>If an error is recoverable or it does not damage the internal state of
an object, it&rsquo;s ok not to raise an error. At the very least, though, a message
should be printed through NSLog.
</p>
<p>Special care should be taken in methods that create resources like
allocate memory or open files or obtain general system resources (locks,
shared memory etc.) from the kernel. If an exception is generated
between the allocation of the resource and its disposal, the resource
will be simply lost without any possibility to release. The code should
check for exceptions and if something bad occurs it should release all
the allocated resources and re-raise the exception.
</p>
<p>Unfortunately there is no nice way to do this automatically in OpenStep.
Java has the &quot;finally&quot; block which is specifically designed for this task. A
similar mechanism exists in libFoundation with the CLEANUP and FINALLY
blocks.
</p>
<hr>
<div class="header">
<p>
Next: <a href="Variable-Declaration.html#Variable-Declaration" accesskey="n" rel="next">Variable Declaration</a>, Previous: <a href="Memory-Management.html#Memory-Management" accesskey="p" rel="prev">Memory Management</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> &nbsp; </p>
</div>



</body>
</html>