Generating Dedicated Error Structs for All Global Errors?

[RedMarcher]

I'm working with Goa v3 and defining a set of global errors at the API level to simplify error handling across my services, as shown in the documentation (e.g., goa.design/docs/3-tutorials/3-error-handling/2-defining-errors/).

My design.go structure for global errors:

// design/design.go
package design

import (
    . "goa.design/goa/v3/dsl"
)

var _ = API("myapi", func() {
    Title("My API")
    Description("API with global errors.")

    // Global error declarations and default mappings
    Error("request_timed_out", func() {
        Description("The request took too long to complete and timed out.")
        // NOTE: No explicit Type() here
    })
    Error("invalid_argument", func() {
        Description("The client provided an invalid or malformed argument in the request.")
        // NOTE: No explicit Type() here
    })
    Error("not_found", func() { // Using 'not_found' as a generic example
        Description("The requested resource could not be found.")
        // NOTE: No explicit Type() here
    })
    // ... many more similar global errors ...

    HTTP(func() {
        Response("request_timed_out", StatusRequestTimeout) // 408
        Response("invalid_argument", StatusBadRequest)     // 400
        Response("not_found", StatusNotFound)             // 404
    })
    GRPC(func() {
        Response("request_timed_out", CodeDeadlineExceeded)
        Response("invalid_argument", CodeInvalidArgument)
        Response("not_found", CodeNotFound)
    })
})

var _ = Service("myService", func() {
    Method("getData", func() {
        Payload(func() { Attribute("id", String) })
        Result(String)
        Error("not_found") // Reference the global error
        HTTP(func() { GET("/data/{id}"); Response(StatusOK) })
        GRPC(func() { Response(CodeOK) })
    })
})

Problem:

When generating code (goa gen my_module_path/design), for errors like not_found (where I haven't specified an explicit Type()), Goa generates Make helper functions (e.g., MakeNotFound). However, returning these errors in my implementation feels verbose:

// In my service implementation
import goa "goa.design/goa/v3/pkg" // required for goa.NewServiceError

func (s *myService) GetData(ctx context.Context, p *myservicegen.GetDataPayload) (string, error) {
    if p.ID == "non-existent" {
        // This is the verbose part I want to avoid
        return "", goa.NewServiceError(nil, "not_found", "Item with ID " + p.ID + " was not found.", false, false, false)
    }
    return "Data for " + p.ID, nil
}

I would prefer to have a dedicated, generated Go struct for each of my global errors, allowing for more concise and type-safe returns, even if these structs only contain a Message field.

Desired Implementation Outcome:

I want to be able to do something like this in my implementation:

// Desired implementation
import myserviceclienttypes "my_module_path/gen/myservice/client" // Assuming generated types are here

func (s *myService) GetData(ctx context.Context, p *myservicegen.GetDataPayload) (string, error) {
    if p.ID == "non-existent" {
        // Much cleaner, type-safe, and directly reflects the error name
        return "", &myserviceclienttypes.NotFound{Message: "Item with ID " + p.ID + " was not found."}
    }
    return "Data for " + p.ID, nil
}

What is the idiomatic or best-practice way in Goa v3 to define global errors in the DSL such that goa gen produces dedicated Go structs for each of them (e.g., type NotFound struct { Message string }) that I can instantiate and return directly, instead of relying on goa.NewServiceError or Make helpers for generic goa.ServiceErrors?

Thank you for your guidance!

[raphael]

Goa generates dedicated constructor methods for errors, see for example https://github.com/goadesign/examples/blob/main/error/gen/calc/service.go#L81-L84. Does that scratch the itch?

[RedMarcher]

Hmm. I took a look, that seems to be an error that's explictely defined in the grpc return type. I was wondering if declaring API level errors could be done, but perhaps not. I guess this at least promotes only declaring the errors that methods should return.