Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gcc 3.3 try - catch -finally

Generally speaking, exceptions are for identifying and handling runtime error conditions and not for catching programmer errors.

The example you first gave, of branching off into never-never land, should never happen. If you wrote a program that did that, it would be a programmer error, not a runtime error. (I know it was just an example. I'm just using it to illustrate my point.)

Similarly, if you write code that tries to (for example) dereference a null pointer, you're going to get a SIGSEGV. That's not a runtime error. It's a programmer error. There's no external condition that could make your pointer valid or null; that happens entirely within your program.

I've never written a single line of Windows code in my life, so I'm not sure I understand exactly what you describe. But it sounds to me like what you're talking about allows the program to deal with things at runtime that should not (in the traditional UNIX paradigm) be dealt with at run time. Segmentation violations *should* be fatal, because they should *never* happen. Adding an exception handler for them implies that they might happen sometimes, and that statement is never true.

(That said, it does sound useful in a way, but there's nothing that you could do in a SEGV handler [for example] that you couldn't more easily do in your debugger after your program has dumped core. If your program still throws SEGV's, you should be running it through your debugger anyway.)

On Friday, June 27, 2003, at 12:33 PM, Marc Poirier wrote:

Sorry for totally off-base post about exceptions being broken in gcc. A
few people have already explained my errors off the list, so I reckon I
should post to tell folks to just ignore what I wrote, it's wrong.

Clearly I need to brush up my understanding of exceptions, but what I was
thinking of were structured exceptions in Windows. Someone told me that
this is actually an issue of signals, not exceptions. These are very
nice, and I guess I'm just not sure if there's something equivalent
available in Mac OS X with gcc. For example, with structured exceptions,
you can do something like this:

__try
{
// do something crazy here
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
DWORD ecode = GetExceptionCode();
if (ecode == EXCEPTION_ACCESS_VIOLATION)
printf("illegit pointer access!\n");
else if (ecode == EXCEPTION_INT_DIVIDE_BY_ZERO)
printf("illegit division by zero!\n");
etc...
}

Or do whatever you want, but basically, it allows you to catch something
and your process doesn't get killed. For my purposes, I am working on
software that hosts plugins, and I'd like to be able to wrap any calls to
the plugin with this sort of thing so that, if the plugin misbehaves, I
can inform the user about this, but not kill the host's process.

So, I'm probably getting far off topic now, but if anyone knows how I
could do something equivalent to Windows structured exceptions in Mac OS
X, I'd love to hear... :)

Marc
_______________________________________________
projectbuilder-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/projectbuilder-users
Do not post admin requests to the list. They will be ignored.



--
email@hidden
http://homepage.mac.com/jharrell
_______________________________________________
projectbuilder-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/projectbuilder-users
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.