un-catched segfault exception

[Christopher Wright]

BCS wrote:
> Christopher Wright wrote:
>> BCS wrote:
>>
>>> Christopher Wright wrote:
>>>
>>>> What you can do, though, is convert a signal to an exception. It's 
>>>> going to be a lot slower than just checking a pointer to see if it's 
>>>> null, but if you have traced exceptions, the debugging benefit is 
>>>> enormous. 
>>>
>>>
>>> Why would this be slow? seg-v are caused by hardware. When a seg-v is 
>>> noticed it triggers an interrupt and the OS goes from there. Until 
>>> you get a seg-v there should be NO cost at all.
>>>
>>> Am I missing something?
>>
>>
>> Handling an error will be slower. Handling a lack of an error will be 
>> faster.
> 
> "Exceptions are a slow way to handle a seg-v's after it happens"
> 
> Ok that makes a difference. I missed that because 1) I generally assume 
> that performance after an errors is not an issue and 2) in general my 
> programs respond to a seg-v by quitting (with an uncaught exception) on 
> the assumption that their is nothing else it can safely do.
> 
> I'd be interested in which of theses assumptions is erroneous in your 
> case and why.

I was speaking about the case where you're using exceptions as flow 
control rather than a means of error handling. So if you're just going 
to catch the segfault exception, log it, and quit, fine; performance 
doesn't matter. If you're going to do something else if you get a 
segfault and it isn't an error, that will be slower. Not to mention 
you'd get pwned in code review.