asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Westmann" <>
Subject Errors, exceptions, and error codes
Date Fri, 15 Jul 2016 18:50:08 GMT

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 
errors, maybe 1 or 2 more) and introduce error codes to identify errors

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, 
    clients, …) as opposed to subclasses of exceptions that need to be 
    in the respective VMs.
2) Error codes (once established) make it easy for customers to search 
    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 
    (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 
for an error. This information that could either be used when handling 
error or when parameterizing a (potential language-specific) error 
E.g. the error message could be "%1$s does not contain %2$s" and %1 and 
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.



View raw message