|
DoSomething() about exceptions
I take exception to exceptions.
I have found the attribute of locality of information to be the single most important measure of the understandability of source code. Such a principle supports functional naming, purposive comments, clean and open structure, carefully designed modularity, and absolutely NO invisible jumping to external code. Exceptions ARE invisible jumps from the local code and thus hide how the local code actually works.
High quality code is hard enough to write and debug without such needless tricks as exceptions. The small amount of added code required to deal directly and locally with the events that cause exceptions are a minor complication compared to invisible functionality.
Lionell Griffith
Thursday, October 16, 2003
Are you saying that if an exceptional condition occurs in a method, it should be dealt with in that method and never communicated to calling methods? I see that you do not like "structured exception handling" but I'm not understanding what you prefer instead. Can you shed some light on things?
interested
Thursday, October 16, 2003
Fsck, man, you people in the forum are crazy.
Exceptions have been implemented by a lot of languages, now:
- C++ has exceptions
- Java has exceptions
- ObjectPascal has exceptions
- Python has exceptions
- Microsoft has implemented in their C language a "structured exception handling" feature
- ... and may other examples
People have implemented exceptions for a reason: they are generally good.
Yes, they may have drawbacks and problems.
But it's a good mechanism, worth having and using.
If you want to go back to error handling by using return values - go ahead, be my guest.
Jed
Thursday, October 16, 2003
"Exceptions ARE invisible jumps from the local code and thus hide how the local code actually works. "
I don't see how exceptions are so invisible.
A function raises or throws an exception visibly, with a raise or throw statement (or whatever the language construct is). Easy enough to see that.
The calling function catches the exception with a visible language construct as well.
If your language has a try...finally construct you can make the cleanup after an error very clear and explicit, and it goes right where it belongs rather than up the call chain.
In real life you have to interface with lots of code that you can't examine or read. All you know is that you call function F and it may succeed or fail. There are many ways it can fail. Whether it communicates those failures to you through a return code or an exception, the code YOU write to deal with the failure is perfectly readable.
There's nothing wrong with locality of information or modular design but those are no more the holy grail of programming than exceptions are. All of the techniques and tools have to be used where they work best.
Gregory Jorgensen
Thursday, October 16, 2003
All of you are making the same sad tired 50+ year old mistake. You presume the primary value of source code is to communicate your dictates to a computer. Nothing could be further from the truth. The primary value of source code is communicating a computrized process to humans - other humans or yourself (assuming programmers are human) some months or years into the future. If this were not true, why aren't you programming directly in machine language?
By using a programming style that reduces the amount you type (likely because you can't type) and justify it because it makes the program more "efficient", you create a text artifact that can only communicate to a computer. You save the computer a few tens of nanoseconds per execution but cost many hours, days, weeks, months of needless effort by those trying to understand your "wonderful" and absolutly "brilliant" code.
The process of creating code is not a lone wolf process of orgasmic passion. Its a social process that must produce an economic result at a minimum of lifetime cost. Exceptions are simply one of many practices that add far more lifetime costs than beneifits.
Simply because you CAN do something is not a valid reason to DO it.
Lionell Griffith
Thursday, October 16, 2003
> Exceptions are simply one of many practices that add far more lifetime costs than beneifits.
You are making the same sad tired millenia old mistake of thinking that asserting something makes it so, not to mention some utterly bogus assumptions about what the rest of us do and don't think.
I said on another thread that trying to prove you *can't* do something is a sucker's game, and that's what you're doing: you're trying to say that we can't use exceptions to communicate intent to other humans in source code. It's utter nonsense, my friend: people can and do all the time.
Finally, this bogus enlightenment that you preach ("by those trying to understand your "wonderful" and absolutly "brilliant" code") is but a step on the True Path. To understand the Fullness, you must *be a geek*, then *reject being a geek*, and then *return to it again*.
Portabella
Thursday, October 16, 2003
Code that communicates clearly is nice, but what I like even better is prose that communicates clearly. Unfortunately, your original post doesn't qualify, as I indicated in my earlier message. How about some clarity?
less interested
Thursday, October 16, 2003
You know, Joel's whole post, and about 95% of the discussion miss one of the more crucial things about exceptions - passing up several layers.
At the place where the error occurs, and at the place where it is handled, error codes and exceptions really look about the same. Sure, the mechanism of getting the error code is slightly different, and exceptions might have additional information attached, but that's sugar.
But all the layers in between, where the "result" code needs to hand up the result, do intermediate cleanup, etc., become *much* clearer with exceptions. Those layers are not directly concerned with the error, because they can't do a thing about it - why should the code still have to handle errors?
- Robert
Groby
Thursday, October 16, 2003
Apparently you are so insulted that I have taken exception to a sacred cow you failed to read what I said. No wonder the bulk of software projects are over budget, over schedule, not to spec, and ultimately cancled. If delivered, the customer accepts because he is desperate to get something - anything.
Please continue your non-sequitors. They are very enlightining about the reason there is so much out-sourcing of IT work these days.
Lionell Griffith
Thursday, October 16, 2003
"The small amount of added code required to deal directly and locally with the events that cause exceptions are a minor complication compared to invisible functionality."
My question is whether by "locally" in this sentence you mean in the same method as where the exception occurs (like local variables) or not. I thought you had some approach that somehow got around passing exceptions/codes up the call stack and I was interested to hear what you had to say.
I see now that you were really just interested in showing how smart and insightful you are by parroting the same tired arguments that have appeared 50 times in other threads, but not quite so clearly. My mistake.
no longer interested
Thursday, October 16, 2003
> you failed to read what I said
No, I *did* read it, and found it completely content-free.
I talked about Enlightenment, because, my friend, you need a Sharp Rap over the Head with a Stick.
I could write an AI program to sound just like you:
"Ah, I see that you think that <fill-in-the-blank-here>. No wonder the IT industry is in such a dismal state, projects late, over-budget, outsourcing, yadda yadda yadda"
Portabella
Thursday, October 16, 2003
"You presume the primary value of source code is to communicate your dictates to a computer. Nothing could be further from the truth. The primary value of source code is communicating a computrized process to humans - other humans or yourself (assuming programmers are human) some months or years into the future. If this were not true, why aren't you programming directly in machine language?"
How about high-level languages make it easier to write code?
"By using a programming style that reduces the amount you type (likely because you can't type) and justify it because it makes the program more "efficient""
It also reduces complexity and makes it more readable, which I think you mentioned earlier has some value.
Ken
Thursday, October 16, 2003
This is really starting to sound like a religious debate. The only thing that is clear to me after reading all of the posts about exceptions is that everyone has a different opinion, and nobody is going to change theirs.
Really the only way I can see to solve this debate is to have fair and impartial study amoung a large amount of unbiased programmers. I personally don't ever see this happening.
craig
Thursday, October 16, 2003
> unbiased programmers
If this board is any kind of sample, then there Ain't No Such Animal.
Portabella
Thursday, October 16, 2003
 Recent Topics
Fog Creek Home
| 
