break (was: NSError: why returned directly?)
break (was: NSError: why returned directly?)
- Subject: break (was: NSError: why returned directly?)
- From: Ondra Cada <email@hidden>
- Date: Thu, 27 Apr 2006 01:14:04 +0200
Erik,
On 27.4.2006, at 0:38, Erik Buck wrote:
I would argue that the use of break statements to break out of
loops prematurely or break out of nested if statements prematurely
only serves to obfuscate code and has no performance advantage
given modern optimizing compilers
Well, I guess we just have to agree to disagree.
In my personal opinion, of course break has no performance advantage,
*but* its real and great advantage is that it makes the code *much*
better readable and maintainable than it would be with all those ugly
artifical booleans and extra blocks which you need to do without.
The same applies for exceptions. It is my experience that the
exception in the innermost method and harness in outermost (with
intermediate ones *only* when dictated by necessity) is a hundred
times better readable and easily maintainable with much less
probability of a typo- or overlooking-based errors, than error code
return-based patterns. The latter inevitably lead to things like
int err=foo();
if (err==0) {
err=bar();
if (err==0) {
... ad inifinitum ...
}
}
return err;
(or any alternative rendering of the same functionality), compared
with the exceptionally plain exceptions-aware pattern (sorry for the
pun):
foo();
bar();
for the author of the code that raises/throws an exception to know
where the control flow will resume unless the exception is handled/
caught in the same compilation unit
Perhaps just my seeing is flawed, but I don't see here any
*conceptual* difference from plain return values. Matter of fact,
@throw and return are, in my world, conceptually the same operations--
they differ only in technical details and easiness of use (which in
some cases may favour return, in other ones @throw), but very not in
principle.
Consider the method
-foo {
if (...) @throw [NSException ....];
return [NSArray ...];
}
may--depending on conditions--return to caller two different results:
an NSException (using one mechanism), or an NSArray (using another
one). In both cases it is entirely dependent on the caller what it
would do with the value, how the result will affect the control flow,
etc. In both cases the amount of information on what the caller
actually will do with the value which we have writing this method is
exactly the same (precisely zilch).
The one difference is that with returned array it is easier to use it
directly and more difficult to promote it up. With exception, it is
the other way round: it is easier to promote up, more difficult to
use directly. That, though, is in my opinion just a conceptually
unimportant technical detail. The basic principle--we provide, the
caller does whatever it wants with it--stays absolutely the same.
Well, your mileage may vary. Given this debate, it self-evidently
does :)
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden