I've read this very interesting blog http://joeduffyblog.com/2016/02/07/the-error-model/ and made me
think what kind of errors do we have in DW. There aren't many but I thought that it would be nice to see
if they are consistent and if we do have a clear idea when we should fail and when we shouldn't.
So the basic idea that this blog shows is that failures should represent uncontrolled behaviour and not normal flow.
This means that the caller of a function should not need to catch failures for normal execution flow.
For that they should model that in the response.
DW Error cases
1/0 (Math Error) => "Division by zero"
[1,2][3]! (Index Error) => "Index 3 is out of bounds"
null ++ "123" (Type dispatch Error) => "Unable to call: ++ with arguments: (Null, "123")."
{}.a! (Invalid field Error) => "There is no key named 'a'"
"Mariano" as Number (Coercion Error) => "Cannot coerce String (Mariano) to Number"
Looking to this they all look like it is ok to think that if any of this expressions fails it is really a code Bug and not something that needs to be catch in a normal flow.
The only issue I found is with the coercions.
Let's take a look at it. We use coercion to adapt a type to another for example
"12" as Number changes the String to a Number. It does a type change.
Now the problem is that sometimes specially for string to dates the user don't know the format the date is being represented
and needs to try different ones. Now the question is, is this a normal flow. Should we have a function
str2Date(str: String) -> String | Null , where null represent it was not able to transform the date.
I think this is something we should definitly have in mind every time we add new apis.
Fail or Return
I've read this very interesting blog http://joeduffyblog.com/2016/02/07/the-error-model/ and made me think what kind of errors do we have in DW. There aren't many but I thought that it would be nice to see if they are consistent and if we do have a clear idea when we should fail and when we shouldn't.
So the basic idea that this blog shows is that failures should represent uncontrolled behaviour and not normal flow. This means that the caller of a function should not need to catch failures for normal execution flow. For that they should model that in the response.
DW Error cases
++with arguments: (Null,"123")."Looking to this they all look like it is ok to think that if any of this expressions fails it is really a code Bug and not something that needs to be catch in a normal flow. The only issue I found is with the coercions.
Let's take a look at it. We use coercion to adapt a type to another for example
"12" as Numberchanges the String to a Number. It does a type change. Now the problem is that sometimes specially for string to dates the user don't know the format the date is being represented and needs to try different ones. Now the question is, is this a normal flow. Should we have a functionstr2Date(str: String) -> String | Null, where null represent it was not able to transform the date.I think this is something we should definitly have in mind every time we add new apis.