Library throws error on empty txlist response

[sebs]

Library throws error on empty txlist response

[slavafomin]

I'm not very familiar with Etherscan API response format, but my guess would be that each section of the API (or a group of sections) have different response format (which leads to an issues like this).

My suggestion would be to actually pass the module and action variables to the getRequest function and to handle the response parsing according to the module/action.

Please, consider the following example:

function getRequest(query, module, action) {

  return client.get('/api?' + query)
    .then(response => {

      const data = response.data;

      switch (module) {

        case 'account':

          /**
          {
            "status": "0",
            "message": "No transactions found",
            "result": []
          }
          */

          if (0 === data.status) {
            return Promise.reject(new Error(data.message));
          } else {
            return data.result;
          }

        default:

          // ... default (common) handling logic

          return data;

      }

    })
    // Probably this catch is not required at all
    .catch(error => {
      if (error instanceof Error) {
        reject(error); // passing as is
      } else {
        reject(new Error(error)); // wrapping in error
      }
    })
  ;

}

It's not a final implementation, but a very much close to it. Also, notice that your implementation could be simplified. No need to call new Promise() because axios already returns a promise.

[sebs]

Throw me a PR, Ill merge all sane code ;)
I guess I would remark if statements when looking at what you propose.

There was a change regarding error reporting and surely this is my bad, i was just to stubborn to follow the specs. I have some time in the 2019 and will put this in.

I might consider using this as a starter for mocks.

Thanks for your time.

[sebs]

Hold your horses with a PR -.....

I guess I will write some swagger definition and re-release the mod as a open api export. This will take some time, but it will tackle the issue of apis giving different responses in a well defined way. + focus is on testing the code and not writing boiler plate stuff.

[sebs]

I guess we have to do #43

[sebs]

can I close this? ;) Not sure atm. If not, there is time to improve more