[jira] Created: (LUCY-60) Low-level error handling

["Marvin Humphrey (JIRA)" <ji...@apache.org>]

Low-level error handling
------------------------

                 Key: LUCY-60
                 URL: https://issues.apache.org/jira/browse/LUCY-60
             Project: Lucy
          Issue Type: New Feature
          Components: Core
            Reporter: Marvin Humphrey
            Assignee: Marvin Humphrey


Have low-level code set a thread-local error variable and communicate failure
via return values, rather than throwing exceptions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (LUCY-60) Low-level error handling

["Marvin Humphrey (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCY-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marvin Humphrey updated LUCY-60:
--------------------------------

    Attachment: lucy_error.diff

It's very important that FileHandle report errors via return codes rather than
throw exceptions.  Because full stack traces are hard to come by under C, we
have to rely upon information that's available in the immediate vicinity when
the glitch occurs to build our error report.  Unfortunately, when FileHandle
encounters a problem such as a failed open() or a failed mmap(), it knows
nothing about the caller, so it can't compose a sufficiently informative error
message on its own.

Crucially, FileHandle doesn't know anything about the sub-files within a
compound file; it always thinks it is operating on the compound file itself,
and that's reflected in its error messages.  If we can at least know the
sub-file, we have a good shot at figuring out the general area where the error
might have occurred, but if we throw exceptions from within
FSFileHandle/RAMFileHandle, we have only the name of the compound file to work
with.

InStream objects, in contrast, know their sub-file -- and the bulk of Lucy
will use InStream objects rather than low-level FileHandles.  If InStream and
Folder check return values from FileHandle and throw exceptions as warranted,
the error messages will be informative enough to give us a fighting chance.

The question then is how to bubble error information up from FileHandle when
an error occurs.   Wikipedia's write-up on the "semipredicate problem" does a
good job laying out the options available to us:

    [http://en.wikipedia.org/wiki/Semipredicate_problem]

One classic technique is to set a global or per-thread error variable, with
C's "errno" being the canonical implementation.  "errno" was originally a
global, but POSIX.1c redefines it as a thread local:

    [http://www.unix.org/whitepapers/reentrant.html]

Theoretically, we could have FileHandle set errno on failure.  However, that
would only work under pthreads; it wouldn't work under anybody else's.

The solution is a per-thread, host-specific error variable -- an object of
type Lucy::Object::Err, isolated behind Err_set_error() and Err_get_error().

Within C code, consumers of low-level objects that set "Err_error" and return
failure will have the option of adding their stack frame data to the Err
object:

{code:none}
if (!FH_Read(fh, buf, length, offset)) {
    ERR_ADD_FRAME(Err_get_error());
    return false;
}
{code}

>From host-space, we have the option of either mirroring the checked API or
detecting failure and throwing exceptions, if the host language's community is
culturally more attuned to exceptions.  

In the present patch, the Perl bindings expose Err_get_error() as Lucy->error,
supporting the following idiom in the tradition of $@, DBI->errstr, etc:

{code:none}
$fh->close or die Lucy->error;
{code}



> Low-level error handling
> ------------------------
>
>                 Key: LUCY-60
>                 URL: https://issues.apache.org/jira/browse/LUCY-60
>             Project: Lucy
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Marvin Humphrey
>            Assignee: Marvin Humphrey
>         Attachments: lucy_error.diff
>
>
> Have low-level code set a thread-local error variable and communicate failure
> via return values, rather than throwing exceptions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (LUCY-60) Low-level error handling

["Marvin Humphrey (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCY-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marvin Humphrey resolved LUCY-60.
---------------------------------

    Resolution: Fixed

Committed as r830061.

> Low-level error handling
> ------------------------
>
>                 Key: LUCY-60
>                 URL: https://issues.apache.org/jira/browse/LUCY-60
>             Project: Lucy
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Marvin Humphrey
>            Assignee: Marvin Humphrey
>         Attachments: lucy_error.diff
>
>
> Have low-level code set a thread-local error variable and communicate failure
> via return values, rather than throwing exceptions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.