Mejorar DX en funciones fallibles #358
Description
Actualmente, las funciones que pueden fallar en Wollok no tienen una forma explícita de indicarlo. Esto impacta negativamente en la experiencia de desarrollo (DX), ya que el comportamiento falible de una función no queda reflejado en su definición ni en su firma.
Por ejemplo:
class Calculadora {
method dividir(a, b) {
if (b == 0) throw new Exception("División por cero")
else return a / b
}
}
En este caso es evidente dónde puede ocurrir un error. Sin embargo, si otra función utiliza dividir, no hay nada en la firma o el contrato que indique que es una operación falible.
Propuesta
Incorporar un modificador de función que explicite que una operación es falible. De forma similar a cómo existe el prefijo override, podría existir el prefijo fallible (o una palabra clave equivalente).
Esto tendría dos consecuencias:
1. Solo se podría utilizar un bloque try/catch dentro de un método marcado como fallible.
2. Una función que invoque a otra falible debería ser marcada también como tal, salvo que maneje el error explícitamente.
Llamado a funciones falibles
Propongo tres operadores para mejorar la ergonomía:
• Inline try (similar a Zig): permite manejar la falla en el mismo lugar de la llamada.
• Propagación con ?: si la función falla, el error se propaga hacia arriba automáticamente.
• Forzado con !: el programador declara que “sabe” que no fallará. Si falla igualmente, se lanza un error en runtime.
Beneficios
• Contratos más claros: el lector del código sabe qué funciones pueden fallar.
• Manejo de errores más consistente.
• Experiencia de desarrollo más predecible y alineada con prácticas modernas (inspiración en Rust, Swift, Zig, etc.).