I think the method currently used by the tool(log and handle at source of
issue) is fine. We don't gain anything by throwing this up to another level
and handling it there, it will just complicate the code. This style
currently used by the CLI tool is adequate since it is not a server that
needs to run continuously but a client application that should exist when
an error is encountered.

In our Java code that runs on the server, having the stack trace helps the
engineer to find the execution flow, but this makes no sense for a client
side CLI tool.

There is no such thing as a standard approach, only the approach that is
most suited for the application, which is different depending on the
application.

On 13 September 2018 at 11:37, Samitha Chathuranga <sami...@wso2.com> wrote:

> Hi,
>
> WSO2 APIM Import Export CLI tool (written in GO Lang) is to be modified to
> support exporting all the artifacts from 2.6.0 environment as bulks, for
> 3.0.0 migration process. There is a concern in how error handling should be
> implemented.
>
> Should it be in a way that all the errors are caught and thrown to the
> top-most level where we log the error messages, print error traces; which
> is the normal standard approach?
>
> Currently normal Import export tool uses below different approach to
> handle errors.
>
> *[pseudo code]* :
> if (error object is not nil or if some other boolean condition is false) {
>     print some logs
>     call HandleErrorAndExit(errorMessage, errorObject) function
> }
>
> For example [1] in ExecutePreCommandWithBasicAuth() function in
> import-export-cli/utils/tokenManagement.go ;
>
> if flagUsername != "" {
>    // flagUsername is not blank
>    if flagUsername != username {
>       // username entered with flag -u is not the same as username found
>       // in env_keys_all.yaml file
>       fmt.Println("Username entered with flag -u for the environment '" +
>          environment + "' is not the same as username found in file '" + 
> EnvKeysAllFilePath + "'")
>       fmt.Println("Execute '" + ProjectName + " reset-user -e " + environment 
> + "' to clear user data")
>       *HandleErrorAndExit*("Username mismatch", nil)
>    } else {
>
> This function is called in import-api.go and export-api.go. For instance 
> whenever an export-api command is given, this
> ExecutePreCommandWithBasicAuth method is called, going through apiExport.go 
> and root.go and this tokenManagement.go files.
>
> But if an error occurred in a function in tokenManagement.go, error is 
> handled in that place itself (log error message/traces and
> exit the program), by calling HandleErrorAndExit(..). HandleErrorAndExit(..)  
> method logs the error messages/traces and exit the program.
> This is how errors are handled currently in the tool. AFAIU this approach is 
> followed as this is a CLI tool, which is
> directly used by the users.
>
> I am suggesting to do this in the standard approach of throwing the errors to 
> the top-most level and handling there when the tool
> is modified for the 3.0.0 migration support. It will facilitate user to get 
> to know of the complete error-occurrence flow.
>
> WDYT?
>
> [1] https://github.com/wso2/product-apim-tooling/blob/
> 30f4677cb8eb35fb09a8e7fa854a07fae8e1864c/import-export-cli/
> utils/tokenManagement.go#L155-L161
>
> --
> *Samitha Chathuranga*
> *Senior Software Engineer*, *WSO2 Inc.*
> lean.enterprise.middleware
> Mobile: +94715123761
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>



-- 
Regards,
Uvindra

Mobile: 777733962
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to