Go Programming talk [OT]

[Andrei Alexandrescu]

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