Skip to content
This repository has been archived by the owner on Oct 15, 2022. It is now read-only.

Throw errors on non-successful responses? #121

Open
deniszgonjanin opened this issue Oct 14, 2020 · 1 comment
Open

Throw errors on non-successful responses? #121

deniszgonjanin opened this issue Oct 14, 2020 · 1 comment
Labels
enhancement New feature or request Future Milestone good first issue Good for newcomers

Comments

@deniszgonjanin
Copy link
Contributor

Requests will fail for network errors, or malformed payloads. However, right now typesuite requests succeed on some errors where you might expect failures. For example, if a PO doesn't exist. Using an example from the Readme:

    const getRequest = new GetRequest({
      baseRef: new RecordRef({
        internalId: "non-existent ID",
        type: "purchaseOrder",
      }),
    });

    const response = await client.get(getRequest).catch(function (error: any) {
      console.log("Error fetching purchaseOrder");
      throw error;
    });

The response:

{
  TYPE_NAME: "com_netsuite_webservices_platform_messages_2019_2.ReadResponse",
  status: {
    TYPE_NAME: "com_netsuite_webservices_platform_core_2019_2.Status",
    isSuccess: false,
    statusDetail: [
      {
        TYPE_NAME: "com_netsuite_webservices_platform_core_2019_2.StatusDetail",
        type: "ERROR",
        code: "UNEXPECTED_ERROR",
        message: "An unexpected error occurred. Error ID: kg9s0roy12yeemm1zpo6e",
      },
    ],
  },
}

The response does show isSuccess: false, but the error handler doesn't throw.

The open question is: should we throw for isSuccess: false? In REST APIs we usually would, but with SOAP the expectations around error handling might be a bit different.

cc @enocom

@BDQ BDQ added enhancement New feature or request Future Milestone good first issue Good for newcomers labels Oct 26, 2020
@enocom
Copy link
Contributor

enocom commented Nov 12, 2020

A better client experience would result in rejected promises for these kinds of errors. And even for errors generally, we probably want a cleaner interface with some custom error types, such that clients need not know about the SOAP implementation details.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request Future Milestone good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants