You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Till Westmann <ti...@apache.org> on 2017/11/07 16:56:53 UTC

Changes to exception handling

Hi,

I’d like to propose some changes to our guidelines for exception
handling. The main motivation is to separate
a) internal errors that are not useful to users and can’t be addressed
   by them (aka bugs) from
b) external errors that inform the user of errors in the input
   (queries/data/…), the environment (disk full/network failure/…), or
   limitations of the system.

For internal errors we'd expect them to not be visible to users and
that the toString() of the exception is logged. These could either be
represented by checked or unchecked exceptions and they would not have
an error code and the error message is in English (i.e. not localized).
If they do reach the user, there would be a generic error message
"internal error" with a suggestion to check the logs.

For external errors we'd expect that users see the getMessage() of the
exception and are able to to address the error condition. These would
always be checked exceptions with an error code and an error message
that could be localized (i.e. the message is in a resource file as we
have them today).

This would be a modification of the existing guideline [1].

Questions/thoughts/concerns?

Cheers,
Till

[1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Exception+Handling

Re: Changes to exception handling

Posted by Mike Carey <dt...@gmail.com>.
+1


On 11/7/17 8:56 AM, Till Westmann wrote:
> Hi,
>
> I’d like to propose some changes to our guidelines for exception
> handling. The main motivation is to separate
> a) internal errors that are not useful to users and can’t be addressed
>     by them (aka bugs) from
> b) external errors that inform the user of errors in the input
>     (queries/data/…), the environment (disk full/network failure/…), or
>     limitations of the system.
>
> For internal errors we'd expect them to not be visible to users and
> that the toString() of the exception is logged. These could either be
> represented by checked or unchecked exceptions and they would not have
> an error code and the error message is in English (i.e. not localized).
> If they do reach the user, there would be a generic error message
> "internal error" with a suggestion to check the logs.
>
> For external errors we'd expect that users see the getMessage() of the
> exception and are able to to address the error condition. These would
> always be checked exceptions with an error code and an error message
> that could be localized (i.e. the message is in a resource file as we
> have them today).
>
> This would be a modification of the existing guideline [1].
>
> Questions/thoughts/concerns?
>
> Cheers,
> Till
>
> [1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Exception+Handling

Re: Changes to exception handling

Posted by Murtadha Hubail <hu...@gmail.com>.
+1

Cheers,
Murtadha

On 11/7/17, 7:56 PM, "Till Westmann" <ti...@apache.org> wrote:

    Hi,
    
    I’d like to propose some changes to our guidelines for exception
    handling. The main motivation is to separate
    a) internal errors that are not useful to users and can’t be addressed
       by them (aka bugs) from
    b) external errors that inform the user of errors in the input
       (queries/data/…), the environment (disk full/network failure/…), or
       limitations of the system.
    
    For internal errors we'd expect them to not be visible to users and
    that the toString() of the exception is logged. These could either be
    represented by checked or unchecked exceptions and they would not have
    an error code and the error message is in English (i.e. not localized).
    If they do reach the user, there would be a generic error message
    "internal error" with a suggestion to check the logs.
    
    For external errors we'd expect that users see the getMessage() of the
    exception and are able to to address the error condition. These would
    always be checked exceptions with an error code and an error message
    that could be localized (i.e. the message is in a resource file as we
    have them today).
    
    This would be a modification of the existing guideline [1].
    
    Questions/thoughts/concerns?
    
    Cheers,
    Till
    
    [1] https://cwiki.apache.org/confluence/display/ASTERIXDB/Exception+Handling