Hi Uvindra,
Thanks for the clarification. Will follow the existing approach.
Regards,
Samitha
On Thu, Sep 13, 2018 at 11:55 AM Uvindra Dias Jayasinha <uvin...@wso2.com>
wrote:
> 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
>
--
*Samitha Chathuranga*
*Senior Software Engineer*, *WSO2 Inc.*
lean.enterprise.middleware
Mobile: +94715123761
[image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
