# Aula 18

# Erros

Quando a gente está começando a programar e somos inseridos ao contexto de erros é comum o pensamento de '**porque diabos eu iria querer causar um erro, eu quero mais é me proteger contra eles**'.

Ao longo da jornada, você percebe que você vai querer causar erros para então tratá-los de maneira específica.

Em geral, você pode utilizar alguns dos erros globais: https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Error

Mas talvez esses erros não façam sentido para todos os contextos, talvez a gente queira especificar algo em particular e tratar isso de maneira única;

    class MyError extends Error {}

Isso seria suficiente para retornarmos um error com name diferente de Error.
Mas um problema nisso é que o stacktrace aparece a construção do nosso erro e a gente não quer isso na maior parte das vezes.

Portanto uma soluçao melhor seria:

    class GoodError extends Error {
        constructor(...args) {
            super(...args)
            Error.captureStackTrace(this, GoodError)
        }
    }

## Sentry.io

Além do óbvio, você vai notar que apenas experiência e Typescript vão te proteger de erros em tempo de execução e por isso é interessante você buscar soluções para entender porque sua aplicação está com problemas.

Sentry é uma dessas soluções que te trazem sanidade novamente. Ele funciona como um agregador e monitor de erros para sua aplicação. Ele possui plano gratuito então é ótimo pra gente testar também.

O processo de você adicionar ele na sua aplicação é ridiculamente simples. Nosso primeiro passo por tanto é entrar no site deles e se cadastrar.

Depois disso, ele vai mostrar **exatamente** o que você deve fazer para que você integre.

Então, como exercício vamos integrar com o Sentry.io, apenas as configurações iniciais são importantes por agora.

A nível de projeto, vamos definir um arquivo de configuração para associar a informação do `dsn` que é a delivery status notifications.

Além disso, vamos precisar adicionar uma extensão ao express, `https://www.npmjs.com/package/express-async-errors`. Hoje, na versão 4.x, o express não lida bem com Promises, a promessa é que na versão 5.x isso seja resolvido.

Por tanto, vamos usar essa extensão para que ele trate nossos errors assíncronos.

## Envio de email

Até o momento, a gente aceita qualquer usuário ser cadastrado na nossa aplicação sem qualquer verificação. É comum fazermos uma validação para termos mais controle sobre quem está de fato usando nossa aplicação e também como maneira de segurança pra diminuir a quantidade de spam ou fake-users dentro dela.

Enquanto a gente viu bastante sobre o protocolo HTTP e razoável que a gente ache que o envio de email pode ser utilizado pelo mesmo protocolo HTTP, no entanto, existe um protocolo específico para envio de email chamado SMTP (Sinple Mail Transfer Protocol);

A gente não precisa se preocupar muito sobre como implementa esse protocolo, podemos utilizar uma biblioteca (**nodemailer**) que nos dá tudo que a gente precisa na implementação, no entanto, vamos precisar utilizar algum serviço externo para envio. Na aula 10, eu sugeri da gente utilizar o **Sendinblue** para ambientes de produção, mas existe outra solução específica para teste chamado **Mailtrap**, e vamos utilizá-lo agora!

A gente pode usar o Mailtrap como alternativa ao serviço de produção por algumas razões: a primeira é a gente não se preocupar em algum email de teste cair em caixa de email de produção por algum uso indevido, e o segundo também poderia ser a gente usa uma quota diferente da quota de envio de emails do serviço de produção o que também é atraente.

O primeiro passo é se cadastrar no site no Mailtrap (https://mailtrap.io), não se preocupe, ele tem um plano gratuito, então é excelente pra gente experimentar.

Depois se cadastrar a gente precisa criar uma inbox. Depois disso, ao acessar essa inbox, vamos ter algumas informações necessárias para utilizarmos o serviço.

Vamos adicionar `nodemailer` como dependência do nosso projeto, `npm add nodemailer`.
Vamos criar uma pasta `mail` em `utils` e lá dentro a gente vai montar o que a gente precisa.

1. Um arquivo config `mail/config.js`
2. Um arquivo index para gerenciar nosso client do nodemailer; `mail/index.js`

Em config.js, vamos adicionar o seguinte:

modules.export = {
    host: "smtp.mailtrap.io",
    port: 2525,
    auth: {
        user: "54252f9b358cff",
        pass: "a37bb8735d2d91"
    },
    secure: false,
    default: {
        from: 'Matching App <[e-mail]>'
    },
};

**Lembrando** que esses credenciais funcionam apenas para o meu projeto, você precisa utilizar as suas que aparecem lá no dashboard do Mailtrap, do contrário, você não vai conseguir ver seus emails de teste.

Depois disso, vamos para nosso `mail/index.js`;

const mailConf = require('./config');

const Mail = nodemailer.createTransport(mailConf);

const sendMail = (message) => {
    return Mail.sendMail({
        ...mailConf.default,
        ...message,
    });
};

module.exports = sendMail;

Isso é o suficiente para utilizarmos o envio de email.

Quando formos chamar isso no nosso código, a gente envia mais algumas informações

const sendMail = require("../utils/mail");

await sendMail({
    to: `${user.name} <${user.email}>`, // destinatário
    subject: `${code} é o seu código de confirmação`, // assunto
    text: "Hello world?", // corpo em texto simples
    html: "<b>Hello world?</b>" // corpo em html
});

Temos um exercício:

1. Replicar esse construção no seu código;
2. Criar o contexto na sua aplicação para que exista os campos `código de confirmação` e `confirmed_at`;
3. Criar a lógica para que o usuário só consiga fazer ações se ele estiver `confirmado`;
4. Extra: método para reenviar email de confirmação;

De uma maneira geral, parece fazer pouco sentido guardar o código de confirmação no banco de dados sendo que ele vai ser utilizado apenas uma vez, e eu concordo. Uma solução mais elegante por exemplo seja guardar essa informação dentro de um banco de dados diferente, como Redis. Se vocês quiserem ler mais sobre ele, vocês podem acessar esse link aqui: https://redis.io/

Nós não vamos entrar aqui em template de email, isso foge um pouco do que a gente precisa.

Mas se vocês quiserem se aprofundar, vocês podem dar uma lida em dois possibilidades:

1. Pug (https://pugjs.org)
2. Handlebarts (https://handlebarsjs.com/)

Qualquer uma das duas opções vai te fornecer uma forma eficiente de você montar seus templates de email.

Além disso, se vocês quiserem algo já responsivo, você pode utilizar o MJML (https://mjml.io/), ele é bem bacana!