El debate sobre la responsabilidad de registrar errores lleva años dividiendo a las comunidades de desarrollo. Una corriente defiende que las aplicaciones registran y gestionan los errores, mientras que las bibliotecas deben limitarse a propagarlos de forma estructurada, enriqueciéndolos con contexto suficiente para que la capa superior decida qué hacer. Otra corriente, predominante en varios ecosistemas, prefiere que las bibliotecas escriban directamente sus propios logs, lo que obliga a menudo a configurar mecanismos para silenciarlos.
La discusión cobró fuerza al analizar el diseño del paquete slog de Go, que admite propagar y enriquecer errores antes de emitirlos. Quienes defienden la propagación argumentan que pasar detalles extra en el valor de retorno permite a la aplicación controlar el nivel de log, añadir contexto y reintentar de forma determinista, sin ruido redundante.
La excepción habitual son las comprobaciones internas demasiado costosas para producción, como aserciones en modo depuración. Las capas de validación de Vulkan son un ejemplo citado: ejecutan comprobaciones exhaustivas solo en builds de desarrollo y no exponen esos fallos como errores propagables, ya que su coste sería prohibitivo en tiempo de ejecución. En estos casos, el log interno en la biblioteca se justifica como herramienta de diagnóstico para desarrolladores, no como canal de notificación al usuario final. La elección depende, en última instancia, de quién consume la información: el desarrollador que depura, o la aplicación que decide cómo responder.