On Tue, 26 Jun 2007 03:20:14 -0000, "Brandon J. Van Every"
<bvanevery@[EMAIL PROTECTED]
> wrote:
>On Jun 25, 10:55 pm, Miss Elaine Eos <M...@[EMAIL PROTECTED]
>
>wrote:
>> In article <1182825713.122029.269...@[EMAIL PROTECTED]
>,
>> "Brandon J. Van Every" <bvanev...@[EMAIL PROTECTED]
> wrote:
>>
>> > I'll reiterate the point in case it's not clear. You're prototyping.
>> > You don't know how you're going to handle your exceptions. You pass
>> > the buck to the caller, because as you said, it's not appropriate for
>> > the function to handle the exception. Nor is it appropriate to
>> > deliberately crash.
>>
>> Oh, sure -- I wasn't arguing that point. I was only pointing out that
>> the world is neither black nor white -- there are situations in which
>> try-catch is appropriate, those where throwing the error up is
>> appropriate and those where error-logging/cra****ng are appropriate.
>>
>> I only meant to point out that it's just as bad to always use one
>> technique as to never use it -- "the right tool for the right job" and
>> all that.
>
>I'm specifically talking about prototyping though. Unless some
>****tion of your prototype is well trodden ground, and you've
>implemented error handling policies dozens of times in the past for
>pretty much exactly the same problem, you're dealing with a lot of
>design instability. My view is that when prototyping, you should be
>banging out your design *quickly*. And it's going to change a lot.
>You could be doing throwaway prototyping, where your code won't even
>exist a month or two from now. Or you could be doing evolutionary
>prototyping, where your code will have mutated in im****tant respects
>from what you started with.
>
>In my view this is just a specific instance of the "You Ain't Gonna
>Need It" programming philosophy (YAGNI).
http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It
>I've overengineered a lot of systems in the past, and sweated an awful
>lot about error handling protocols, only to see it prove irrelevant in
>the real world of code change. My view is that worrying about C++
>exception handling merely slows down development in the early stages
>of design. I say skip it. In fact, skip any kind of error return at
>all. It's very likely that You Ain't Gonna Need It.
>
>You definitely need to issue warnings, generate logs, and do***ent the
>various ways your code can fry, however. Even when prototyping. It's
>usually pretty easy to write out some string that says, "This code
>just fried this way." It's a form of commentary, and it does
>something useful during debugging.
>
>
>Cheers,
>Brandon Van Every
my experience is that try-catch are quite ok to avoid some nasty popup
to user about unhandled exception.. that is about it. designing a
program that intelligently recovers from errors using try/catch is
just too complicated. it is better just to log if an error occurs and
then log so close to where it happened as possible.
my 0.02
ajk
|
