Define Errors Out of Existence

Difference between version 4 and 5 - Previous - Next
[Define Errors Out of Existence] is a principle described by [John Ousterhout] in [A Philosophy of
Software Design].



** See Also **

   [TIP #323: Do Nothing Gracefully]:   Lists various procedures that do nothing rather than returning an error.

   [https://en.wikipedia.org/wiki/Robustness_principle%|%Robustness principle]:   Perhaps another articulation of the same principle.



** Description **
'''Define errors out of existence''' is related to the principle of '''deep
interfaces''', also described in [A Philosophy of Software Design].  A deep
interface provides relatively high functionality compared to the complexity of
the interface.  Defning errors out of existence is one technique that can help
to achieve a deep interface:  Instead of returning an error, a the procedure
handles a condition if it reasonably can.  Ousterhout uses `[unset]` as an 
example of a procedure that should have used to
 this strategy.  Instead, it 
returns an error if a named variable does not
 exist.



** Examples **

    `[concat]`:   Effectively concatenates multiple lists into a single list if all its arguments are actually lists, but doesn't care if some arguments are not lists.  It's the caller's job to either ensure that they are or to decide it likes the result if they aren't.

   `[dict exists]`:   Does not return an error if the first value is not a dictionary.  Instead, the answer is "no".  Apparently it was decided that it is preferable to allow a script to continue under that false assumption that it is working with dictionary.

   `[encoding convertto] ` and `[encoding convertfrom]`:   `[encoding convertto]` does not return an error if a character can not be encoded in the target encoding, and `[encoding convertfrom]` does not return an error if the source encoding contains invalid encoded data.

   `[file delete]`:   Does not return an error if a file to delete doesn't exist.

   `[lindex]` and `[lrange]`:   There is no integer that results in an error.  Negative integers and integers larger than the index of the last item are all perfectly acceptable.  If `[lindex]` is only given one argument, it simpley returns that value, regardless of whether it's a list

   `[binary scan]`:   Does not return an error when it encounters a character having a [Unicode] code point greater than 255.  Instead, it reads only the lower byte of the, ignores higher byte.  Apparently in this case it was decided that data loss is preferable to returning an error.



** Page Authors **

   [pyk]:   



<<categories>> A Philosophy of Software Design