View mode: basic / threaded / horizontal-split · Log in · Help
December 21, 2010
Re: try...catch slooowness?
Walter Bright wrote:
> Michel Fortin wrote:
>> Exceptions are slow, that's a fact of life. The idea is that an
>> exception should be exceptional, so the case to optimize for is the
>> case where you don't have any exception: a try...catch that doesn't
>> throw. Other ways to implement exceptions exists which are faster at
>> throwing (setjmp for instance), but they're also slower at entering
>> and exiting a try..catch block when no exception occur.
>
> [...]
>
>> Exceptions are recommended to avoid cluttering your normal code flow
>> with error handling code. Clearly, in the code above exceptions are
>> part of the normal code flow. That's not what exception are made for.
>
> Right on all counts. Exceptions are for *exceptional* cases, i.e.
> unexpected errors, not normal control flow.

Exceptions (actual ones and not just a reference to any particular error 
handling mechanism) are EXPECTED errors. That follows directly from the 
goal of keeping programs running by handling of errors that were thought 
about at design time. Show me an unexpected error and I'll show you a 
bug.

>
> The implementation is designed so that the speed normal execution is
> strongly favored over speed of exception handling.
December 21, 2010
Re: try...catch slooowness?
Steven Schveighoffer wrote:

> An exception is a recoverable error,

Not necessarily. At some point, all the handling options could have been 
tried but all failed in which case there is nothing left to do except for 
letting something higher up (like the operating system) deal with the 
situation. In such a case, recovery did not occur if you consider 
recovery to mean that the program keeps running normally.

> Exception handling is
> great when it exists at a much higher level, because you can
> essentially do all error handling in one spot, and simply write code
> without worrying about error codes.

That sounds like the common misconception that leads to weak designs.
December 22, 2010
Re: try...catch slooowness?
On Tue, 21 Dec 2010 17:16:57 -0500, Rob <rob2970@yah00.com> wrote:

> Walter Bright wrote:
>> Michel Fortin wrote:
>>> Exceptions are slow, that's a fact of life. The idea is that an
>>> exception should be exceptional, so the case to optimize for is the
>>> case where you don't have any exception: a try...catch that doesn't
>>> throw. Other ways to implement exceptions exists which are faster at
>>> throwing (setjmp for instance), but they're also slower at entering
>>> and exiting a try..catch block when no exception occur.
>>
>> [...]
>>
>>> Exceptions are recommended to avoid cluttering your normal code flow
>>> with error handling code. Clearly, in the code above exceptions are
>>> part of the normal code flow. That's not what exception are made for.
>>
>> Right on all counts. Exceptions are for *exceptional* cases, i.e.
>> unexpected errors, not normal control flow.
>
> Exceptions (actual ones and not just a reference to any particular error
> handling mechanism) are EXPECTED errors. That follows directly from the
> goal of keeping programs running by handling of errors that were thought
> about at design time. Show me an unexpected error and I'll show you a
> bug.

No they aren't.  They are anticipated, but not expected.  For instance, an  
I/O error is not *expected*, but it is anticipated as possible if say the  
config file is not readable, but it's not expected to happen for a normal  
operation.  In this case, the exception most likely kills the program  
(can't do much without a config), but the program handles the error  
gracefully and prints a readable message rather than just "Broken Pipe" or  
something like that.

-Steve
December 22, 2010
Re: try...catch slooowness?
On Tue, 21 Dec 2010 17:25:09 -0500, Rob <rob2970@yah00.com> wrote:

> Steven Schveighoffer wrote:
>
>> An exception is a recoverable error,
>
> Not necessarily. At some point, all the handling options could have been
> tried but all failed in which case there is nothing left to do except for
> letting something higher up (like the operating system) deal with the
> situation. In such a case, recovery did not occur if you consider
> recovery to mean that the program keeps running normally.

In D, unrecoverable errors derive from Error, recoverable ones derive from  
Exception.

By 'recovery' I mean that the program can either continue to run or decide  
proactively to do something different (like print an error and exit).  But  
control is still in the programmer's hands.

>> Exception handling is
>> great when it exists at a much higher level, because you can
>> essentially do all error handling in one spot, and simply write code
>> without worrying about error codes.
>
> That sounds like the common misconception that leads to weak designs.

So you tell me, what is a good design with exceptions?  Because it seems  
like doing:

try fn()
catch(Exception) {...}

is pretty ugly and cumbersome (and clearly has performance issues), when  
it could be:

if(fn() != 0)
  ...

To me, if you are surrounding a single low-level call with an exception  
handler, your design has issues.

-Steve
December 22, 2010
Re: try...catch slooowness?
Steven Schveighoffer wrote:
> On Tue, 21 Dec 2010 17:16:57 -0500, Rob <rob2970@yah00.com> wrote:
>
>> Walter Bright wrote:
>>> Michel Fortin wrote:
>>>> Exceptions are slow, that's a fact of life. The idea is that an
>>>> exception should be exceptional, so the case to optimize for is the
>>>> case where you don't have any exception: a try...catch that doesn't
>>>> throw. Other ways to implement exceptions exists which are faster
>>>> at throwing (setjmp for instance), but they're also slower at
>>>> entering and exiting a try..catch block when no exception occur.
>>>
>>> [...]
>>>
>>>> Exceptions are recommended to avoid cluttering your normal code
>>>> flow with error handling code. Clearly, in the code above
>>>> exceptions are part of the normal code flow. That's not what
>>>> exception are made for.
>>>
>>> Right on all counts. Exceptions are for *exceptional* cases, i.e.
>>> unexpected errors, not normal control flow.
>>
>> Exceptions (actual ones and not just a reference to any particular
>> error handling mechanism) are EXPECTED errors. That follows directly
>> from the goal of keeping programs running by handling of errors that
>> were thought about at design time. Show me an unexpected error and
>> I'll show you a bug.
>
> No they aren't.  They are anticipated,

That is how the term "expected" is used in the literature. Read up. No 
need to play semantical/literal games. It's the concept that is relevant. 
The point is that saying that exceptions are unexpected is incorrect by 
just about any paper, article or book on error handling, save for those 
that get that wrong also (A. Andrescu's early book gets it wrong also, as 
I recall, FWIW).
December 22, 2010
Re: try...catch slooowness?
Steven Schveighoffer wrote:
> On Tue, 21 Dec 2010 17:25:09 -0500, Rob <rob2970@yah00.com> wrote:
>
>> Steven Schveighoffer wrote:
>>
>>> An exception is a recoverable error,
>>
>> Not necessarily. At some point, all the handling options could have
>> been tried but all failed in which case there is nothing left to do
>> except for letting something higher up (like the operating system)
>> deal with the situation. In such a case, recovery did not occur if
>> you consider recovery to mean that the program keeps running
>> normally.
>
> In D, unrecoverable errors derive from Error, recoverable ones derive
> from Exception.
>
> By 'recovery' I mean that the program can either continue to run or
> decide proactively to do something different (like print an error and
> exit).

That, decidedly, from common terminology usage industry-wide, is 
considered "unrecoverable". "Unrecoverable" doesn't mean crash and burn. 
Anything less than the program staying running is indicates something 
unrecoverable happened.
December 22, 2010
Re: try...catch slooowness?
On Wed, 22 Dec 2010 15:21:52 -0500, Rob <rob2970@yah00.com> wrote:

> Steven Schveighoffer wrote:
>> On Tue, 21 Dec 2010 17:16:57 -0500, Rob <rob2970@yah00.com> wrote:
>>
>>> Walter Bright wrote:
>>>> Michel Fortin wrote:
>>>>> Exceptions are slow, that's a fact of life. The idea is that an
>>>>> exception should be exceptional, so the case to optimize for is the
>>>>> case where you don't have any exception: a try...catch that doesn't
>>>>> throw. Other ways to implement exceptions exists which are faster
>>>>> at throwing (setjmp for instance), but they're also slower at
>>>>> entering and exiting a try..catch block when no exception occur.
>>>>
>>>> [...]
>>>>
>>>>> Exceptions are recommended to avoid cluttering your normal code
>>>>> flow with error handling code. Clearly, in the code above
>>>>> exceptions are part of the normal code flow. That's not what
>>>>> exception are made for.
>>>>
>>>> Right on all counts. Exceptions are for *exceptional* cases, i.e.
>>>> unexpected errors, not normal control flow.
>>>
>>> Exceptions (actual ones and not just a reference to any particular
>>> error handling mechanism) are EXPECTED errors. That follows directly
>>> from the goal of keeping programs running by handling of errors that
>>> were thought about at design time. Show me an unexpected error and
>>> I'll show you a bug.
>>
>> No they aren't.  They are anticipated,
>
> That is how the term "expected" is used in the literature. Read up. No
> need to play semantical/literal games. It's the concept that is relevant.
> The point is that saying that exceptions are unexpected is incorrect by
> just about any paper, article or book on error handling, save for those
> that get that wrong also (A. Andrescu's early book gets it wrong also, as
> I recall, FWIW).

Sorry, I guess I dummer than you.

-Steve
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home