Email requests using unverified email address in from field are not thrown

[OussamaFadlaoui]

Subject of the issue

I used the Node SDK package resend to send my first email. Upon using an unverified domain in the from field, my request seemed to go OK (promise was not rejected). When I went to the dashboard, I discovered the request was rejected with status code 403:

That's a valid point, however, why did the Promise not throw an appropriate error?

Steps to reproduce

1. Create Resend account
2. Install resend NPM package
3. Send an email in Node.js using an unverified domain name in the from field

Expected behaviour

The promise should be rejected on 403 status codes..

Actual behaviour

No errors being thrown.

[bukinoshita]

Hey @OussamaFadlaoui, would you mind sharing the request you're sending?

[everybodyloveshaggis]

@bukinoshita - an example I can give to back up @OussamaFadlaoui 's example is this

let data;
    try {
        data = await resend.emails.send({
            from: 'onboarding@resend.com',     //this is wrong on purpose to throw an error
            to: 'BLANKED_OUT_FOR_QUESTION_RESPONSE@gmail.com',
            subject: 'Message from cv-site-nextjs',
            reply_to: senderEmail as string,
            react: React.createElement(ContactFormEmail,
                {
                    senderMessage: senderMessage as string,
                    senderEmail: senderEmail as string
                }),
        });
        //interrogation required to check for error
        if(data.error?.message !== undefined)
        {
            throw data.error;
        }
    } catch (error: unknown) {
        return {
            error: getErrorMessage(error),
        };
    }

You'll see I have had to interrogate the data object to pull out the child error object with the below

 if(data.error?.message !== undefined)
        {
            throw data.error;
        }

as I do not hit the catch block even though the following error is displayed on the UI

[vcapretz]

hey there, in the latest versions of the SDK basically all methods should always return correctly and not throw any errors, we do that so in your codebase you don't have to wrap our code in a try/catch method.

if the requests fail for any reason, our SDK will return a populated error object with some description of what happened.

using the example for an unverified domain the error object will be like:

{
  statusCode: 403,
  message: 'The test.com domain is not verified. Please, add and verify your domain on https://resend.com/domains',
  name: 'validation_error'
}

please let us know if the issue still persists and feel free to reopen it in here 🙏

[OussamaFadlaoui]

hey there, in the latest versions of the SDK basically all methods should always return correctly and not throw any errors, we do that so in your codebase you don't have to wrap our code in a try/catch method.

if the requests fail for any reason, our SDK will return a populated error object with some description of what happened.

using the example for an unverified domain the error object will be like:

{
  statusCode: 403,
  message: 'The test.com domain is not verified. Please, add and verify your domain on https://resend.com/domains',
  name: 'validation_error'
}

please let us know if the issue still persists and feel free to reopen it in here 🙏

Obviously this is not my library, but I still want to say that having tries and catches all over code does not take away from the quality of a library. In fact, it is the proper way of handling errors. After all, this library is performing a promise, and promises are expected to either resolve or reject

Therefore I find the reasons for this design decision to be a bit odd and steering away from the traditional way of using promises in third party libraries.