Got it. Thanks! Best, Taewoo
On Fri, Jul 15, 2016 at 1:30 PM, Till Westmann <[email protected]> wrote: > There’s not example so far. I think/hope that we’ll see one in one of > Abdullah’s bug fixes :) > > > On 15 Jul 2016, at 13:16, Taewoo Kim wrote: > > 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 <[email protected]> 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/ >>> >>>
