Azure / typespec-azure

About TypeSpec Azure Libraries
https://azure.github.io/typespec-azure/
MIT License
15 stars 41 forks source link

[tcgc] refine error usage #1853

Open tadelesh opened 1 week ago

tadelesh commented 1 week ago

for current tcgc behavior, the error usage will only on models with @error decorator, or models extends model with @error. it does not have any propagation. for this example, ErrorResponse will have usage Error | Output, and ErrorDetail will have usage Output. the problem here is:

  1. the error does not have propagation which makes it is only a flag, and you could not know error model's reference type
  2. @error is used implicitly as an http exception response in typespec http lib. we have requirement to know if a model is only used in exception response.

after discussed with @ArcturusZhang , we come up with the following proposal:

  1. remove Error usage, add a helper function that indicate if a tcgc type is annotated with @error.
  2. add Exception usage, and for all models used in exception response, they will no longer have Output usage, but have Exception usage. with above example, ErrorResponse will have usage Exception, and ErrorDetail will have usage Exception. and call isError for ErrorResponse return true, while for ErrorDetail return false.
haolingdong-msft commented 1 week ago

I like the proposal to remove error usage and add exceptionusage, but just wondering do we need isError helper function to indicate the model has @error decorator? What does downstream use this information for? And to me, the helper function name isError is a bit confusing. If the helper function indicates whether the model has decoratoror not, the name would better be something like hasErrorDecorator to reduce confusion.

tadelesh commented 1 week ago

i think it is just for a replacement for error usage, but i'm fine we do not add it if no languages do need that. i just do not remember clearly how we use error usage for all languages.