On 06/09/2010 06:28 AM, Pelle wrote:
On 06/09/2010 01:04 AM, Leandro Lucarella wrote:
Bane, el 8 de junio a las 14:42 me escribiste:
Is a trade-off. When you don't handle the errors, exceptions might be
a win, but when you do handle them, I'm not so sure. And again, I'm
not
saying I particularly like one more than the other, I don't have a
strong opinion =)
Of course, the problem is that you rarely see the former code. Most
of the time, people just write the second one with or without
exceptions and don't bother about error checking if there are no
exceptions. You are a lot more likely to get them to handle errors
properly with exceptions than without (particularly with D's scope
statements).
Being lazy as I am, exceptions are faster and easier to use than
manual error checking. There will always be some unchecked return
value, with exceptions it can't happen. In a way same as GC vs manual
memory handling.
Each thread of program I make I always enclose in try catch, so
everything is cought.
Yes, I agree that "safety" is the best argument in favour of exceptions
(as explicitness is the best argument in favour of no-exceptions). The
Python Zen put it this way:
Errors should never pass silently.
Unless explicitly silenced.
That's what I like the most about exceptions. I think try/catch is
really ugly though. There has to be something better.
Careful use of scope(exit) and simply avoiding catching exceptions works
well for me. Except when you have to catch, of course. :)
Same here. I think a good application only has few try/catch statements,
so the fact that try is a relatively heavy statement is not very important.
Andrei
