I don’t see the point of a Result type in dynamically typed languages. They exist in typed languages so the compiler can make sure we’re handling success and failure in our code before we run it. But if we’re in a dynamically typed language we’ve already decided that we want to push all sorts of checks to the run-time of the program, so the obvious solution is exceptions which force you to handle an error.
They force you to unwrap them to use the value, which makes it obvious that a possible error needs to be handled (especially at code review time). Good for common / expected error conditions.
But how is that any better than an exception? You’re going to get an exception if you don’t unwrap it and you don’t have anything before running the code to ensure you are unwrapping.
Forcing the unwrapping means that if you forget to unwrap then your code will always fail.
If an exception is only thrown on errors, then your code will work…. until it doesn’t work. So you deploy your code and everything breaks.
I think that Result types make a lot of sense in cases where you really want to make sure both cases are handled. Exceptions are better for super rare stuff where you want your app to fall over if they happen
Exceptions are exceptional so it’s easy to write bad code that assumes they will not happen. Writing code that homogenizes the happy and sad paths forces you to handle both cases consistently. I look at it as helping with discipline.
I don’t see the point of a Result type in dynamically typed languages. They exist in typed languages so the compiler can make sure we’re handling success and failure in our code before we run it. But if we’re in a dynamically typed language we’ve already decided that we want to push all sorts of checks to the run-time of the program, so the obvious solution is exceptions which force you to handle an error.
They force you to unwrap them to use the value, which makes it obvious that a possible error needs to be handled (especially at code review time). Good for common / expected error conditions.
But how is that any better than an exception? You’re going to get an exception if you don’t unwrap it and you don’t have anything before running the code to ensure you are unwrapping.
Forcing the unwrapping means that if you forget to unwrap then your code will always fail.
If an exception is only thrown on errors, then your code will work…. until it doesn’t work. So you deploy your code and everything breaks.
I think that Result types make a lot of sense in cases where you really want to make sure both cases are handled. Exceptions are better for super rare stuff where you want your app to fall over if they happen
Exceptions are exceptional so it’s easy to write bad code that assumes they will not happen. Writing code that homogenizes the happy and sad paths forces you to handle both cases consistently. I look at it as helping with discipline.