adds error handling support

[baywet]

Summary

fixes #411

Adds error handling to kiota clients (more details on the logic being applied in the markdown document part of this PR).

I've already logged Error conversion adjustments in the conversion library to fix the last quirks (mostly hardcoded names conflicting with languages naming conventions).

All the examples below result in the following output

Could not find a property named 'displayName2' on type 'microsoft.graph.message'.

Selecting displayName2 is intentional to have the service return an error.

CSharp usage

try {
     var mailFoldersResult = await client.Users["vincent@biret365.onmicrosoft.com"].MailFolders["Inbox"].GetAsync(q => {
        q.Select = new string[] { "id", "displayName2"};
     });
 } catch (Error ex) {
    Console.WriteLine(ex.Error_prop.Message);
}

Go usage

client := u.NewApiClient(adapter)
options := &m.MessagesRequestBuilderGetOptions{
    Q: &m.MessagesRequestBuilderGetQueryParameters{
        Select: []string{"id", "displayName2"},
    },
}
response, err := client.UsersById("vincent@biret365.onmicrosoft.com").Messages().Get(options)
if err != nil {
    casted, ok := err.(*sdkerr.Error)
    if ok {
        fmt.Print(*((*casted.GetError()).GetMessage()))
    } else {
        fmt.Printf("Error getting messages: %v\n", err)
    }
    return
}

Java usage

try {
    var mailFoldersResult = client.users("vincent@biret365.onmicrosoft.com").mailFolders("Inbox").get(q -> {
        q.select = new String[] { "id", "displayName2"};
    }).get();
    System.out.println("Hello world!" + messagesResult.getValue().size() + mailFoldersResult.getDisplayName());
} catch (java.util.concurrent.ExecutionException ex) {
    Throwable innerEx = ex.getCause();
    if(innerEx instanceof graphjavav4.utilities.models.odata.Error) {
       graphjavav4.utilities.models.odata.Error error = (graphjavav4.utilities.models.odata.Error) innerEx;
       System.out.println(error.getError().getMessage());   
    }
}

TypeScript usage

const client = new ApiClient(requestAdapter);
try {
  const messagesResult = await client.usersById("vincent@biret365.onmicrosoft.com").mailFoldersById("Inbox").get({
  select: ["displayName2", "id"]
  });
  console.log(`messages Folder display name ${messagesResult?.displayName}`);
} catch(err) {
   console.log(`Error: ${(err as Error_escaped).error_escaped?.message}`);
}

Todo list

(this is for me, and also for other languages owners to understand how this is implemented)

TODO CSharp

• update code-gen to pass the error mapping in executor methods to request adapter
• update request adapter interface to accept the error mapping
• update request adapter implementation to use error mapping during response handling
• use the new refiners in the language refiner + unit tests
• bump versions for abstractions and http packages
• code-gen unit tests
• update the response handler interface to accept the error mapping
• add intermediate exception type in abstraction and have generated types derive from that instead

TODO TypeScript

• update code-gen to pass the error mapping in executor methods to request adapter
• update request adapter interface to accept the error mapping
• use the new refiners in the language refiner + unit tests
• update request adapter implementation to use error mapping during response handling
• bump versions for abstractions and http packages
• code-gen unit tests
• update the response handler interface to accept the error mapping
• add intermediate exception type in abstraction and have generated types derive from that instead

TODO Java

• update code-gen to pass the error mapping in executor methods to request adapter
• use the new refiners in the language refiner + unit tests
• update request adapter interface to accept the error mapping
• update request adapter implementation to use error mapping during response handling
• bump versions for abstractions and http packages
• code-gen unit tests
• update the response handler interface to accept the error mapping
• add intermediate exception type in abstraction and have generated types derive from that instead

TODO Go

• update code-gen to pass the error mapping in executor methods to request adapter
• use the new refiners in the language refiner + unit tests
• update request adapter interface to accept the error mapping
• update request adapter implementation to use error mapping during response handling
• bump versions for abstractions and http packages
• code-gen unit tests
• update the response handler interface to accept the error mapping
• add intermediate exception type in abstraction and have generated types derive from that instead

TODO global

• refiner to inherit from exception for classes marked as error
• refiner that adds a reference to error types in class usings
• refiner to add usings for exception type when a class is error
• ping PHP team to reflect changes
• list that change in ruby catch up
• ping python team to reflect changes
• add changelog entry
• update conceptual docs

Generation diff

microsoft/kiota-samples#498

Description being used

microsoftgraph/msgraph-sdk-powershell#1060

[sebastienlevert]

What is the plan for the Error vs Error_escaped? MicrosoftGraphError ? Or something else? How it is right now feels awkward, but I love the approach to have native errors like that! If we can figure out the right type to use, I'm happy with the result!

Should I expect that the result would be :

try {
      const messagesResult = await client.usersById("vincent@biret365.onmicrosoft.com").mailFoldersById("Inbox").get({
        select: ["displayName2", "id"]
      });
      console.log(`messages Folder display name ${messagesResult?.displayName}`);
    } catch(err) {
        console.log(`Error: ${(err as Error).message}`);
    }

err.error being kinda weird, knowing we are expecting an error here.

[andrueastman]

👍🏼 Looks good to me.

[nikithauc]

https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#extending-built-ins-like-error-array-and-map-may-no-longer-work

Object.setPrototypeOf(this, ApiError.prototype); 

This should be set in the Error classes extended from APIError. That is, in the generation process.

[nikithauc]

@sebastienlevert
This is what you should expect once we fix the last conversion issues. This is because of OData conventions, object responses (the error in that case) are always wrapped in a parent object.

console.log(`Error: ${(err as Error).error?.message}`);

Error is the predefined JS error right? Does that accept an internal object, as far as I know it just accepts strings in the constructor?

@baywet I am missing this conversation in the chain. Are we continuing with Error_Escaped as seen in here in the samples?

[baywet]

@nikithauc, sorry I forgot this aspect, added

As per the error type it'll be

console.log(`Error: ${(err as ODataError).error?.message}`);

thanks to there latest changes. microsoft/OpenAPI.NET.OData#174

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

89.6% Coverage
0.0% Duplication