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

Marc Poirier wrote:
| Clearly I need to brush up my understanding of exceptions, but what I was
| thinking of were structured exceptions in Windows.

Which are very much a non-standard use of exceptions. Standard C++ exceptions are produced only one way: by executing a "throw" statement.


| Someone told me that this is actually an issue of signals, not
| exceptions.

The particular items you mention in the sample code are signals. Whether all the Microsoft-specific extensions are signals, I don't know.


| 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...
| }

Those "__" marks are the giveaway that this isn't standard C++ code. Any name containing two underscores in a row (anywhere in the name) is reserved for the implementation to define as it pleases. (Gcc defines its own collection of keywords using the same approach. And, for completeness, it's best to avoid names starting with one underscore and a capital letter, too, for the same reason.)


| 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.

Look into the signal() call and its brethren. Be warned, however: signal handers are practically *defined* to be undefined. There is virtually *nothing* you can do safely in a signal handler more elaborate than setting a "this signal happened" flag and returning, because you know virtually nothing about the state of the process as a whole, or what your program was doing at the moment the signal was sent. (The same is true of "structured exceptions"--you don't know that the EXCEPTION_ACCESS_VIOLATION wasn't caused by the stack having been overwritten by garbage--but making it a language construct suggests that it makes sense to do something other than as clean an exit as you can manage.)

Glen Fisher
_______________________________________________
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.
References: 
 >Re: gcc 3.3 try - catch -finally (From: Marc Poirier <email@hidden>)



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.