asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taewoo Kim <wangs...@gmail.com>
Subject Re: Errors, exceptions, and error codes
Date Fri, 15 Jul 2016 20:16:35 GMT
It's a great idea. Can you show us a before/after example that you have
replaced already in your branch if there is any?

Best,
Taewoo

On Fri, Jul 15, 2016 at 11:50 AM, Till Westmann <tillw@apache.org> wrote:

> 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/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message