Hacker News Reader

Comment by joefreeman | Hacker News Reader

On the homepage, on the left of the page it says, "thanks to its error handling model you will never have to worry about unexpected runtime errors" - then, one of the examples on the right says:

    # This will produce a runtime error,
    # because `Integer + String` is not valid:
    dynamic(2, 'oops')

So, we don't have to worry about this runtime error because it's expected?

View on HN

I suspect there might be a better way of phrasing this, though I am not quite sure how.

The example you are showing here relies on dynamic typing. When you use dynamic typing, pretty much all bets are off. When the website mentions error handling, it talks specifically about using exceptions. Take for example the following Ruby code:

    def foo
      # lots of code here
      raise TypeError, 'Foo must be of type X'
    end

When you call this method, you have no idea what it might raise. If you're lucky somebody might have documented this, or maybe there is a test that clearly shows this. This is what we mean with unexpected errors: an error popping up (intentionally or not) that you were not aware of.

Inko tries to tackle this by requiring you to tag methods with the error type, and limits you to only a single error type per method. Combined with having to use `try` or `try!` for such methods, this makes it immediately clear that (and what) a method might throw. If a method tries to throw without the tag, it will not compile.

No, IIUC in Inko your method won't compile unless you either A) Define this method as throwing exceptions B) Catch the exception inside the method

Reply on news.ycombinator.com