Mailing-List: contact dev-help@asterixdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.apache.org
From: "Till Westmann" <tillw@apache.org>
To: dev@asterixdb.apache.org
Subject: Errors, exceptions, and error codes
Date: Fri, 15 Jul 2016 11:50:08 -0700
Message-ID: <785475B4-5099-4B7A-AE88-9B0544004CD3@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
archived-at: Fri, 15 Jul 2016 18:50:48 -0000

Hi,

triggered by a recent bug fix that required an non-trivial error
reporting/handling workflow across the Hyracks/AsterixDB boundary, I’d 
like to
propose a change/extension to the way we manage exceptions.

The change is that we’d limit the number of exception classes to a 
very few
(HyracksDataException for runtime errors, AlgebricksExeptions for 
compiler
errors, maybe 1 or 2 more) and introduce error codes to identify errors
further.

The use of error codes has a number of advantages:
1) Error codes usually use simple types (strings or integers) and thus 
make it
    easy to be transported across system boundaries (Hyracks, AsterixDB, 
VXQuery,
    clients, …) as opposed to subclasses of exceptions that need to be 
available
    in the respective VMs.
2) Error codes (once established) make it easy for customers to search 
for
    existing solutions (try to google for e.g. "ORA-12154" [1] :) ).
3) Error codes can be used a a key for error messages in different 
languages
    (if we want to expand our reach).

I’ve created en example of what this could initially look like for
HyracksDataException [2]. You’ll see there that I propose to add
a) a component (e.g. "Hyracks", "Hyracks Storage", "AsterixDB", …),
b) an error code (that is unique within a component), and
c) an array of Serializable objects
to the HyracksDataException. While the component and the error code are 
used to
uniquely identify an error, the array is used to provide additional 
information
for an error. This information that could either be used when handling 
the
error or when parameterizing a (potential language-specific) error 
message.
E.g. the error message could be "%1$s does not contain %2$s" and %1 and 
%2
would be substituted with actual values when reporting the error.

Please take a look at the proposal and reply with questions, comments,
suggestions, or alternatives.

Thanks,
Till

[1] https://www.google.com/search?q=ORA-12154
[2] https://asterix-gerrit.ics.uci.edu/#/c/1000/