Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fail or Return #22

Open
machaval opened this issue Jan 30, 2021 · 0 comments
Open

Fail or Return #22

machaval opened this issue Jan 30, 2021 · 0 comments

Comments

@machaval
Copy link
Contributor

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

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant