Re: NSError: why returned directly?
Re: NSError: why returned directly?
- Subject: Re: NSError: why returned directly?
- From: Erik Buck <email@hidden>
- Date: Wed, 26 Apr 2006 18:38:04 -0400
On Apr 26, 2006, at 2:19 PM, Ondra Cada wrote:
Erik,
On 26.4.2006, at 16:07, Erik Buck wrote:
We have all been reminded that “goto” is seldom a good idea.
Well, an exception is a “goto” with a destination that can not be
predicted by the author of the code that generates the exception
(“goto”). Exceptions are the most pathological example of goto
that is possible.
Exceptions are -- conceptually -- much rather (non-local) breaks
than (non-local) gotos. Do you advocate against break, too?
The C break statement is a variant of goto. I may be mistaken, but I
believe the one and only situation when the break statement is
required to be used in C is in switch() case: compound statements.
However, like a goto used within a single compilation unit, it is
generally possible to inspect a single compilation unit and identify
every possible control flow through the compilation unit even if
break statements are used. 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. However, it
is possible to see what the code does in spite of the gratuitous use
of break statements.
Exceptions are like goto statements or break statements in that they
cause a change in control flow. Exceptions are worse and more
problematic that either goto or break to the extent that it is
impossible 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 I have just never see a good example of exception usage. I
don't think any of the common Java frameworks use exceptions well,
and Cocoa doesn't either in my opinion. The closest I have come to
appreciating exceptions in in the Eiffel language, and I suspect I
like that usage best more because of conventions used than language
features used.
_______________________________________________
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