IMO, robustez é um lado de um trade-off de design e não um princípio de "preferência". Como muitos apontaram, nada cheira a soprar quatro horas tentando descobrir onde seu JS errou apenas para descobrir que o verdadeiro problema era que apenas um navegador fazia a coisa certa com o XHTML Strict. Ele deixou a página ficar em pedaços quando alguma parte do HTML exibido foi um desastre completo.
Por outro lado, quem deseja procurar documentação para um método que aceita 20 argumentos e insiste em que estejam exatamente na mesma ordem que os locais vazios ou nulos para os que você deseja ignorar? A igualmente robusta maneira robusta de lidar com esse método seria verificar cada arg e tentar adivinhar qual deles era baseado em posições e tipos relativos e, em seguida, falhar silenciosamente ou tentar "sobreviver" com argumentos sem sentido.
Ou você pode aumentar a flexibilidade no processo passando uma lista de pares de valores literais / dicionário / valor-chave de objeto e lidando com a existência de cada argumento à medida que você chega a ele. Para o tradeoff de perf menor, é um cenário de bolo e de comer também.
Sobrecargas de argumentos de maneira inteligente e consistente com a interface é uma forma inteligente de ser robusto sobre as coisas. Assim, a redundância de cozimento é um sistema em que se presume que a entrega de pacotes não será entregue regularmente em uma rede maciçamente complicada de propriedade e operada por todos em um campo emergente de tecnologia com uma ampla variedade de meios potenciais de transmissão.
Tolerar a falha de abjeto, no entanto, especialmente dentro de um sistema que você controla, nunca é uma boa troca. Por exemplo, eu tive que fazer uma pausa para evitar jogar um chiado em outra pergunta sobre colocar o JS no topo ou na parte inferior da página. Várias pessoas insistiram que era melhor colocar JS no topo, porque se a página não fosse carregada completamente, você ainda teria alguma funcionalidade. Páginas de meia-obra são piores do que bustos completos. Na melhor das hipóteses, eles resultam em mais visitantes para o seu site corretamente assumindo que você é incompetente antes de descobrir sobre isso, se a página rebocada é simplesmente devolvida a uma página de erro ao falhar sua própria verificação de validação seguida por um e-mail automatizado Alguém que pode fazer algo sobre isso. Você se sentiria à vontade para passar as informações do seu cartão de crédito para um site que estava sempre preso?
Tentar entregar a funcionalidade de 2010 em um navegador de 1999, quando você poderia apenas fornecer uma página de tecnologia inferior, é outro exemplo de uma troca de design insensata. As oportunidades perdidas e o dinheiro que eu vi desperdiçado com o tempo gasto pelo desenvolvedor em soluções cheias de bugs apenas para obter cantos arredondados em um elemento que paira acima de um fundo gradiente, por exemplo, me afastaram completamente. E para quê? Para fornecer páginas tecnológicas mais avançadas que tenham um desempenho fraco em relação a technophobes comprovados, limitando suas escolhas em navegadores de maior porte.
Para que seja a escolha certa, a escolha de manipular entradas de maneira robusta deve sempre facilitar a vida em ambos os lados do problema, no curto e no longo prazo.