Re: Real life cost of using exceptions for control flow?
From: Alvin Bruney [MVP] (vapor)
Date: 06/17/04
- Next message: Chris: "Re: BinaryWriter.Flush and BufferedStream.Flush"
- Previous message: Jon Skeet [C# MVP]: "Re: Real life cost of using exceptions for control flow?"
- In reply to: Jon Skeet [C# MVP]: "Re: Real life cost of using exceptions for control flow?"
- Next in thread: Jon Skeet [C# MVP]: "Re: Real life cost of using exceptions for control flow?"
- Reply: Jon Skeet [C# MVP]: "Re: Real life cost of using exceptions for control flow?"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 17 Jun 2004 11:17:40 -0500
>Following your "never throw any exceptions" convention
Where is it that this came from me? Can you copy and paste it in here
please.
>Do you really *never*
> catch any exceptions raised by your own code, except at the very top
> level?
I'm confused by this. I don't know where it came from. What I am saying is
that convention dictates that exceptions should not be used to control
program flow. This is the point of the entire thread. You are arguing that
it really doesn't matter and that convention can be broken because
exceptions aren't all that expensive.
That's wrong in principle because that sort of coding practice leads to
unreadable, unmaintainable, inefficient code. Which is why bruno pointed out
that control flow is a better approach than having exceptions determine
flow. If you are off track on this thread, you should re-read it from the
top again. I don't mind waiting. I got nothing else to do today.
Code which has to bend a natural design into all kinds of
> knots just to avoid ever throwing an exception is just as bad as code
> which throws too many exceptions, in my view.
The sum of your argument is that your machine can throw a couple thousand
exceptions without consequence. These are your words, not mine. If you cant
see that as disturbing then this thread is pointless. By convention - which
means not using exceptions to control code flow - natural design of code
follows from this premise. If you designed it properly with flow, it
wouldn't be bent out of shape in the first place. You are arguing after the
fact which is a baseless, faulty premise.
I've been eyeing this thread for a long while without getting involved but I
must jump in because certain people have a greater moral responsibility than
others. It often means tailoring responses for the greater good of
programming. This *is one such case where you should be touting convention
over your opinion because a greater good is served to everyone by siding
with convention. When you stand on principle like that, you lead others
astray because you cause them to break with convention. And convention in
this case is good.
-- Regards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27*** "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:MPG.1b3bc2d464d774d298acc0@msnews.microsoft.com... > <"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote: >> > We've said before we'll have to agree to disagree on this. While the >> > answer is often "No", I don't believe it *always* is. >> >> No. Just say you are wrong on this. > > What, say I'm wrong when I don't believe I am? Do you really *never* > catch any exceptions raised by your own code, except at the very top > level? > >> Look how many million programmers now think its ok to throw a thousand >> exceptions per hour after reading this thread. And they'll be using your >> logic to justify it. And they should rightly be fired for it! You need to >> correct this, at least for the sake of keeping with convention. > > If their simple design happens to fire a thousand exceptions in an > hour, but keeps the system working well, rather than using complicated > and error-prone logic to avoid those thousand exceptions, I don't > believe they *do* deserve to get fired. > >> You may not necessarily find it wrong but programmers with less >> experience >> will follow blindly and produce misbehaved applications. There's a good >> reason why convention dictates a clear path forward. Programmers with a >> lot >> of experience who know what they are doing are free to bend the rules how >> they see fit because they understand the consequences. Inexperienced >> programmers need to follow convention untill they learn the reasons why >> convention is in place. > > Could you explain how any of that goes against what I said about it > Bruno's approach *often* being the right one but not *always* being the > right one? > > Following your "never throw any exceptions" convention blindly is just > as wrong as following a convention of "throw exceptions here, there and > everywhere". Code which has to bend a natural design into all kinds of > knots just to avoid ever throwing an exception is just as bad as code > which throws too many exceptions, in my view. > > -- > Jon Skeet - <skeet@pobox.com> > http://www.pobox.com/~skeet > If replying to the group, please do not mail me too
- Next message: Chris: "Re: BinaryWriter.Flush and BufferedStream.Flush"
- Previous message: Jon Skeet [C# MVP]: "Re: Real life cost of using exceptions for control flow?"
- In reply to: Jon Skeet [C# MVP]: "Re: Real life cost of using exceptions for control flow?"
- Next in thread: Jon Skeet [C# MVP]: "Re: Real life cost of using exceptions for control flow?"
- Reply: Jon Skeet [C# MVP]: "Re: Real life cost of using exceptions for control flow?"
- Messages sorted by: [ date ] [ thread ]