5 ms·
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
by joefreeman 7y ago
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?
- jashmatthews 7y agoNo, 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
- YorickPeterse 7y agoI 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.