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/
