On Wed, Dec 19, 2012 at 7:55 PM, Brendan Eich <bren...@mozilla.com> wrote:
> John J Barton wrote:
>
>> On Wed, Dec 19, 2012 at 11:23 AM, Brendan Eich <bren...@mozilla.com<mailto:
>> bren...@mozilla.com>> wrote:
>>
>> The value of (2) is low but real.
>>
>>
>> I disagree. (2) is essential exactly because we depend on subsystems.
>>
>
> Disagree on "low" or "real"? Evidently not "real", so must be "low". What
> I mean is using try/catch near the event loop to drop a "do not understand"
> exception on the floor instead of allowing it to terminate the loop (or do
> whatever an uncaught exception would do) is pretty low-value. Perhaps the
> event loop auto-restarts without a catch. Is the canonical console.log of
> the uncaught exception useful? Only if a developer is watching.
>
throw happens at any depth and trapping the throw in a development system
is -- or should be -- one of the fundamental operations supporting
development. An exception may arrive from outside of the developers
control, but during development most exceptions are bugs. In a dynamic
development environment we are mostly handling exceptions because our code
far from our goal. In a dynamic system syntax errors, reference errors, and
many kinds of algorithm errors surface as exceptions. Eventually we
approach our goal and the normal code has no exceptions. Unless we have
foolishly polluted our error handling mechanism with non-errors.
>
> My "low" does not mean "zero" -- that would take away the "real" value I
> ascribed. But it's pretty silly to say that try/catch for (2) is highly
> useful, in the sense that it adds a lot of value. If event loops
> auto-respawn it's at best a convenience and logging opportunity.
That's a very pessimistic view. The primary goal for try/catch should be
to guard our code from subsystem issues. That means the try/catch should be
near the bottom of our stack, where we cross over. Placing try/catch at the
top for logging just means the subsystems are unpredictable and our
development solutions are so primitive we must resort to logging.
>
>
>> StopIteration is only one example of (1).
>>
>>
>> And one too many, exactly because (2) is so vital. We should not pollute
>> the critical feature of "throw exceptions" with "throw because I can't
>> figure out another implementation"
>>
>
> The two use-cases are almost always disjoint. StopIteration is almost
> always auto-handled by for-of constructs.
Nevertheless the StopIteration triggers the exception handling machinery as
if it were an exception. The fact that it is handled by a catch is sadly
opaque to this machinery.
> The mistake of including StopIteration should not be used to
>> justify including more mistakes.
>>
>>
>> This is Crockfordian in its dire sweep but I don't think you've
>> made the case. What's your preferred alternative?
>>
>>
>> Don't include features that require StopIteration.
>>
>
> The alternatives are worse. We've been over this. If you don't have
> something new to propose, you're not going to move the needle here at all.
I'm only trying to prevent the needle from moving further, as proposed by
Claude.
I don't have any interest in StopIteration, but it seems pretty obvious
that an alternative could be created:
dry {
mayDhrowStopIteration();
} datch(iStopped) {
geeImDone();
}
That is, the entire try/catch/throw machinery could be copied and wired
into new syntax for the StopIteration case. The dry/datch/dhrow would be
independent of try/catch/throw.
Such a solution make the cost of StopIteration much higher, as it should
be. By hi-jacking the exception machinery, the cost of StopIteration is
artificially low. That is what we mean by a hack: a way of accomplishing a
goal that shifts costs on to others in the future.
jjb
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
