Should not throw APIException when response code is 400

[chumingwu]

When posting an update transaction, the Resp API return response code 400 with validation error, but the NetStandard Api will throw APIException. It should not throw APIException, it should just return Response Object with validation error.

These AccountingApi methods have that issue

public Task<BankTransactions> UpdateBankTransactionAsync(string accessToken, string xeroTenantId, Guid bankTransactionID, BankTransactions bankTransactions, int? unitdp = null);

public Task<CreditNotes> UpdateCreditNoteAsync(string accessToken, string xeroTenantId, Guid creditNoteID, CreditNotes creditNotes, int? unitdp = null);

public Task<Invoices> UpdateInvoiceAsync(string accessToken, string xeroTenantId, Guid invoiceID, Invoices invoices, int? unitdp = null);

[jenksguo]

Hi @chumingwu we are working to improve the validation error soon.

I would like to hear more from you on what kind of behaviour you expect.

If we still throw APIException and pass an ValidationException object, but expect developer to use try catch block to use the SDK, would this be able to better the experience?

[chumingwu]

Jenks,

I would like the API do NOT throw Exception when API response 400 with validation error , just return the data with validation error.

All Create methods is in this way already.

public Task<BankTransactions> CreateBankTransactionsAsync(string accessToken, string xeroTenantId, BankTransactions bankTransactions, bool? summarizeErrors = null, int? unitdp = null);

public Task<Contacts> CreateContactsAsync(string accessToken, string xeroTenantId, Contacts contacts, bool? summarizeErrors = null);

But currently some Update Mothods (Post) will throw APIException when API server return validation error.

public Task<BankTransactions> UpdateBankTransactionAsync(string accessToken, string xeroTenantId, Guid bankTransactionID, BankTransactions bankTransactions, int? unitdp = null);

[jenksguo]

Hi @chumingwu we will investigate and align the behaviour between update and create methods.

[jenksguo]

Hey @chumingwu, just to let you know we will be working on the validation behaviour this sprint so hopefully we will address the issue you mentioned soon.

[nganbread]

@jenksguo @GraceYBR any updates on this?

Throwing exceptions should be for exceptional circumstances, which validation is not normally considered to be

[rjaus]

@nganbread jenks has moved on from Xero. @RettBehrens is heading up SDKs now, so he’s your best bet for .net.

[yosefmah]

Hi @RettBehrens @rjaus - is this still something that is planned or being worked on? We are also finding it difficult to handle this as an ApiException instead of ApiResponse. Thanks

[nganbread]

The lack of response/action by Xero is super disappointing considering that Xero is a paid product and also considers itself to be a tech company

[rjaus]

Heya @yosefmah. I was contracting with Xero, but I finished up in December last year. @RettBehrens is your best bet going forward.

[KieranFoot]

Issues like this really do require attention. I am currently using my own branch of your code due to similar issues. (Item not found throwing APIException). Also, since my company paid for an account for me to even develop for you, we will not be crating pull requests against this repo.