PROCESS

Aqui é Como Construir

Design

Regras

O caso que a regra não encaixa

Uma regra é como um requisito é cumprido no caso normal. As Regras tomaram uma só regra e mostraram-na inteira, cinco decisões desenhadas como uma, sólida quando concordam. Mas uma regra constrói-se para o caso normal, e nem todo o caso é normal. Mais cedo ou mais tarde chega um caso que a regra não encaixa, e o Executor que o encontra não pode avançar pela regra, porque para este caso a regra não tem nada a dizer. Esse caso é uma exceção, e este volume trata dele: como se encontra, como se leva o Executor através dele, e como, com o tempo, se faz desaparecer.

Começa pelo que a exceção não é. Não é uma regra partida, nem uma regra mal feita. Uma regra sólida, desenhada com todo o cuidado, ainda encontra casos para os quais não foi construída, porque nenhuma regra pode prever toda a forma que o trabalho tomará. A exceção não é uma falha da regra; é a sua borda, o lugar onde o caso normal termina e começa algo que a regra não antecipou. Por isso a existência de exceções não é sinal de mau design. Todo o design tem bordas. O que separa o bom design do mau não é se as exceções existem, mas se o Executor que encontra uma fica encalhado ou é levado através, e se à exceção se permite repetir-se para sempre ou se é desenhada para que desapareça.

O Executor está no centro disto, e vale ser claro sobre porquê. Quando um caso que a regra não encaixa chega ao Executor, ele está preso de uma maneira particular: o trabalho não pode continuar, e nada lhe diz o que fazer. Pode adivinhar, e arriscar-se a fazer mal. Pode ficar em silêncio, e deixar o cliente às escuras. Ou pode pegar num caminho a seguir que o design preparou de antemão. Todo este volume é o esforço do designer por assegurar que esse terceiro caminho exista sempre, que quando a regra se cala, o design não se cale. Uma exceção é, antes e depois de tudo, um momento em que uma pessoa precisa de saber o que fazer, e o design já deve ter respondido.

O padrão mais elevado possível é tratar cada exceção como um caso que a regra não encaixa e uma pessoa que precisa de um caminho através, nem um defeito de que ter vergonha nem uma raridade a ignorar, mas uma borda do design a prever, gerir e, com o tempo, remover.

Conclusão chave: Uma regra constrói-se para o caso normal, e nem todo o caso é normal; o caso que a regra não encaixa é uma exceção, onde o Executor não pode avançar porque a regra não tem nada a dizer. Uma exceção não é uma regra partida mas a borda de uma, o lugar onde o caso normal termina; todo o design tem bordas, e o que separa o bom do mau não é se as exceções existem mas se o Executor fica encalhado ou é levado através, e se a exceção se repete para sempre ou é desenhada para desaparecer. No seu centro uma exceção é uma pessoa que precisa de saber o que fazer, e o design já deve ter respondido.

Uma exceção é um caso que a regra não encaixa, e um Executor que precisa de um caminho através onde a regra se calou.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 1: Uma Exceção · Secção: O caso que a regra não encaixa

MarvinPro | Junho 2026

marvinpro.com

O que o mundo chama uma exceção, e o que é

Pergunta o que é uma exceção, e a maioria das respostas vem do mundo dos sistemas. Aí, uma exceção é um erro, um erro lançado quando um programa encontra um estado que não pode gerir, capturado e gerido por uma maquinaria construída para isso. A palavra carrega esse peso: algo correu mal, soou um alarme, um gestor deve capturá-lo. Este é um sentido verdadeiro da palavra, e não é o sentido que este livro quer dizer. A exceção aqui não é um erro numa máquina. É um caso no trabalho que a regra não antecipou, encontrado por uma pessoa, não por um programa.

Por isso põe de lado o sentido da máquina e toma o mais simples. Uma exceção é uma resposta desenhada a uma condição definida sob a qual a regra normal não se aplica, um caso onde a regra é descartada intencionalmente, cumprida de outra maneira, ou levada a alguém que possa decidir. A condição é o que marca o caso como excecional, este não é o caso normal, a regra não encaixa aqui. A resposta é o que o design faz a esse respeito. E por baixo, na maioria das exceções, o requisito mantém-se de pé. O cliente ainda deve ser informado, o registo ainda deve estar certo; é só que a regra normal para cumprir o requisito não encaixa neste caso, por isso o requisito é cumprido de outra maneira. De vez em quando um requisito é descartado deliberadamente para um caso definido, o cliente que pediu para não ser contactado, com razão, não é contactado, mas muito mais vezes o requisito sobrevive e a exceção é simplesmente uma rota diferente para o mesmo fim.

É por isto que uma exceção se desenha, não se improvisa. A máquina do mundo captura um erro depois de ser lançado; o designer, ao invés, prevê o caso antes de ele chegar e constrói a resposta de antemão. Uma exceção, neste livro, não é algo que te acontece. É algo que desenhas, uma resposta preparada para um caso que sabias que podia vir, para que quando venha, o Executor não fique a inventar uma resposta no momento. A diferença entre uma exceção capturada e uma exceção desenhada é a diferença entre um processo que se safa e um processo que foi construído para se sustentar.

O padrão mais elevado possível é entender por exceção não o erro de uma máquina capturado depois do facto, mas uma resposta desenhada a um caso previsto que a regra não encaixa, preparada de antemão para que o requisito ainda se cumpra e o Executor nunca fique a improvisar.

Conclusão chave: O sentido comum de exceção vem dos sistemas, um erro lançado e capturado por uma maquinaria; este livro quer dizer outra coisa, um caso no trabalho que a regra não antecipou, encontrado por uma pessoa. Uma exceção é uma resposta desenhada a uma condição definida sob a qual a regra normal não se aplica: a condição marca o caso como não normal, a resposta é o que o design faz, e por baixo o requisito costuma manter-se de pé e é cumprido de outra maneira, embora de vez em quando seja descartado deliberadamente. A exceção desenha-se de antemão, não se improvisa no momento, a diferença entre um processo que se safa e um construído para se sustentar.

Uma exceção não é o erro de uma máquina capturado depois do facto, mas uma resposta desenhada a um caso previsto que a regra não encaixa.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 1: Uma Exceção · Secção: O que o mundo chama uma exceção, e o que é

MarvinPro | Junho 2026

marvinpro.com

Tão poucas quanto possível

Há uma tentação, tendo aprendido a gerir bem as exceções, de se orgulhar de quantas se conseguem gerir. Resiste-lhe. A medida de um design não é com quanta riqueza gere exceções mas quão poucas tem. Cada exceção é um lugar a que as regras não chegaram, um caso que o design normal não conseguiu cobrir. Geri-la bem é necessário, o Executor deve ser levado através, mas gerir é uma reparação, não um triunfo. Um processo carregado de exceções é um processo cujas regras estão incompletas, por muito elegantemente que cada exceção seja gerida.

Por isso este volume sustém dois fins ao mesmo tempo, e o segundo governa o primeiro. O primeiro fim é gerir: quando uma exceção chega, dar ao Executor um caminho sancionado a seguir, nunca encalhado. O segundo fim é remover: desenhar a exceção para que desapareça, de modo que com o tempo o trabalho precise cada vez menos delas. Não estão em tensão; são uma sequência. Geres a exceção hoje porque está aqui e o Executor precisa de um caminho através. Removes-la amanhã dobrando o caso recorrente de volta às regras, para que deixe de ser uma exceção de todo. Um bom designer faz ambas, e nunca confunde a primeira com o trabalho inteiro. Gerir uma exceção e deixá-la de pé para sempre é gerir uma fuga em vez de a reparar.

Este é o fio que percorre cada disciplina que segue. Quando trazes uma exceção à luz, estás a encontrar um vazio nas regras. Quando dás ao Executor um caminho a seguir, estás a gerir esse vazio com cuidado. E quando dobras o caso recorrente de volta às regras, estás a fechar o vazio, para que a exceção não seja mais precisa. O fim, sustido firmemente desde o primeiro e se até à última dobra, é um design com tão poucas exceções quanto possível, onde quase cada caso que o trabalho encontra é, mais uma vez, um caso que as regras já encaixam.

O padrão mais elevado possível é sustentar, através de todo o trabalho que segue, que gerir bem uma exceção é necessário mas nunca o objetivo, e que o objetivo é sempre um design com tão poucas exceções quanto possível, cada recorrente dobrada de volta às regras.

Conclusão chave: A medida de um design não é com quanta riqueza gere exceções mas quão poucas tem; cada exceção é um lugar a que as regras não chegaram, e geri-la é uma reparação, não um triunfo. O volume sustém dois fins, e o segundo governa o primeiro: gere a exceção hoje, porque o Executor precisa de um caminho através, e remove-a amanhã, dobrando o caso recorrente de volta às regras para que deixe de ser uma exceção. Gerir uma exceção e deixá-la de pé para sempre é gerir uma fuga em vez de a reparar.

Gerir bem uma exceção é necessário mas nunca o objetivo; o objetivo é um design com tão poucas exceções quanto possível.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 1: Uma Exceção · Secção: Tão poucas quanto possível

MarvinPro | Juin 2026

marvinpro.com

Um exemplo real

Volta à empresa de software, através da lente da exceção. A maior parte do que o Executor encontra é uma incidência conhecida: um problema que a empresa já viu antes, com um modelo pronto e um caminho a seguir escrito. A regra encaixa, e o Executor avança. Este é o caso normal, e a maioria dos casos é normal, o que é o design a funcionar como deve.

A exceção é a incidência desconhecida, o problema sem modelo, porque ninguém ainda o compreende o suficiente para escrever um. Aqui a regra não encaixa. O Executor enfrenta um cliente com um problema e não tem nada escrito para enviar, nenhuma instrução para seguir. Não pode avançar pela regra, porque para este caso não há regra. E isto não é uma regra partida nem uma descuidada; é a borda de um design sólido, o lugar onde o conhecido termina e começa algo novo. Nenhum conjunto de modelos, por completo que seja, poderia ter previsto cada problema que o software poderia um dia produzir. A incidência desconhecida é a borda do design, e encontrá-la não é uma falha mas uma inevitabilidade.

O que separa este design de um pobre é o que acontece a seguir. O Executor não fica a inventar uma resposta nem a cair em silêncio. Um caminho a seguir foi construído de antemão, a via de escalonamento, que leva o caso a quem o pode trabalhar, com atualizações moldadas para manter o cliente informado entretanto. E a exceção não dura: uma vez o problema compreendido e resolvido, é transformado num guia de resolução e em modelos, e o desconhecido torna-se conhecido, dobrado de volta às regras para que o próximo Executor simplesmente avance. A exceção é gerida hoje e removida amanhã. É todo este volume, visto num caso: um Executor levado através da borda do design, e a própria borda, com o tempo, desenhada para desaparecer.

Uma exceção é a borda de um design sólido, um caso que a regra ainda não encaixa, encontrado com um caminho a seguir hoje e dobrado nas regras amanhã.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 1: Uma Exceção · Um exemplo real

MarvinPro | Junho 2026

marvinpro.com

Uma Exceção

Uma regra é como um requisito é cumprido no caso normal, mas nem todo o caso é normal. O caso que a regra não encaixa é uma exceção, e o Executor que o encontra não pode avançar pela regra, porque para este caso a regra não tem nada a dizer. Uma exceção não é uma regra partida nem uma descuidada; é a borda de um design sólido, o lugar onde o caso normal termina e começa algo que a regra não antecipou. Todo o design tem bordas, por isso a existência de exceções não é vergonha nenhuma. O que separa o bom design do mau é se o Executor que encontra uma é levado através ou fica encalhado, e se à exceção se permite repetir-se para sempre ou se é desenhada para que desapareça.

O sentido comum da palavra no mundo vem dos sistemas, um erro lançado e capturado por uma maquinaria. Este livro quer dizer outra coisa: um caso no trabalho que a regra não antecipou, encontrado por uma pessoa. Uma exceção, aqui, é uma resposta desenhada a uma condição definida sob a qual a regra normal não se aplica, a regra descartada intencionalmente, cumprida de outra maneira, ou levada a alguém que possa decidir. A condição marca o caso como não normal; a resposta é o que o design faz a esse respeito; e por baixo, na maioria das exceções, o requisito mantém-se de pé e é simplesmente cumprido de outra maneira, embora de vez em quando seja descartado deliberadamente. A exceção desenha-se de antemão, não se improvisa no momento, uma resposta preparada para um caso que sabias que podia vir.

E o objetivo, sustido da primeira disciplina à última, é precisar de tão poucas quanto possível. A medida de um design não é com quanta riqueza gere exceções mas quão poucas tem, porque cada exceção é um lugar a que as regras não chegaram. Por isso o volume sustém dois fins, o segundo governando o primeiro: gere a exceção hoje, para que o Executor nunca fique encalhado, e remove-a amanhã, dobrando o caso recorrente de volta às regras até deixar de ser uma exceção. Gerir uma exceção e deixá-la de pé para sempre é gerir uma fuga em vez de a reparar.

Isto é o que as disciplinas que seguem vão construir. Trarás exceções à luz perguntando aos Executores os seus e se, muito antes de o trabalho entrar em funcionamento. Triá-las-ás, incorporando o que puderes e pondo honestamente de lado o resto. Darás ao Executor um caminho a seguir, escrito onde se pode e escalonado onde se deve. E dobrarás as recorrentes de volta às regras, até que o trabalho, mais uma vez, encontre quase cada caso com uma regra que encaixa. Uma exceção é um caso que a regra não encaixa e uma pessoa que precisa de um caminho através; a tarefa do designer é ver que o caminho através esteja sempre ali, e que a exceção, no fim, não esteja.

Uma exceção é um caso que a regra não encaixa e um Executor que precisa de um caminho através; o design deve responder onde a regra se calou, e depois fechar o vazio para que não se cale mais.

MarvinPro · PROCESS · Aqui é Como Construir · Design · Exceções · Disciplina 1: Uma Exceção · Resultado do Capítulo

MarvinPro | June 2026

marvinpro.com

Pensa Simples.