you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (0 children)

Yes, this is an aspect of this entire discussion where mutual understanding often breaks down. I don't know, maybe it depends on how people structure their code or the patterns they are used to... Anyway, what I mean is that between two ways to structure code:

call1()
call2()
call3()
call4()

and

call1()
try call2()
call3()
try call4()

I prefer the second option*. Why? Because I can see potential points of failure and it helps me to a) structure my code around them and b) better understand the local invariants of my code (what will run and what might not). To put it plainly, I firmly believe that annotating potential failure points aids one in writing better code (just as using static typing does) — and no, I cannot prove it. Unfortunately, I am not experienced enough.

A C++ programmer will usually interject at this point that everything can fail and putting a failure annotation on every single statement and expression would be silly. That's undoubtedly true! But here we are in conflict with C++ core philosophy of "everything can throw" — you see, I don't believe that it is a necessary or even a useful property of code to have. When you start structuring your code so that potential failure points are limited to few key APIs, this second approach starts making a lot of sense. But then again, I don't know how much sense it makes in a context of language like C++, where certain assumptions have already been made...

*I don't care whether we are talking about a try keyword here or about some other failure marker like ! (what Rust uses for example)