TweetFollow Us on Twitter

C++ Exceptions
Volume Number:11
Issue Number:10
Column Tag:C++ Workshop

Try C++ Exception Handling

How to make use of the C++ exception standard in your C++ code

By Kent Sandvik

Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.

Exception handling is a feature of the ANSI C++ specification first formally proposed back in 1990, but only recently adopted by compilers on the Macintosh. This has changed with compiler level support for exceptions in CodeWarrior 6, and the promise that Symantec will provide this feature in their C++ compiler soon.

For developers used to working with class libraries, exception handling is nothing new. MacApp, TCL, PowerPlant all have provided macros to implement this feature with setjump/longjmp calls. However, there are still a number of manual steps for the programmer because this technique can interact with compiler optimizations. Supporting exceptions directly in the compiler, which has the ability to make sure that variables and stack information, including C++ objects, are valid between exception cases means that the framework and developers don’t need to worry about these runtime issues. In addition, this means that C++ code is more portable across computer environments.

Most of the C++ literature dealing with exception handling tends to be academic and doesn’t show how C++ exception handling is used in real life. This article will get you started if you want to add standard C++ exception handling into your current project. I will describe what exception handling is, how it works and how to implement exception handling using the proposed ANSI C++ syntax. We will also discuss some pitfalls and design issues.

Error Handling and Exceptions

The generalized model for exception handling is to have, within a part of a program, separate execution paths for normal execution and error recovery. When an error (exception) is detected, the program can ‘throw’ it to the error recovery code (exception handler). The recovery code may then attempt to recover from the error and resume normal program execution, or do some clean up and pass control to the next handler. As noted above, errors are called exceptions, and the error recovery code is called an exception handler.

It is important to note that exception handling is just one of many ways to deal with error cases. The following are some other error reporting techniques used by software engineers:

• Return an error status from the function (OSErr)

• Global error variable (errno in UNIX environments, QDErr and similar low mem globals on the Mac side, fortunately we have functions to return these errors nowadays)

• Invocation of a special, user-defined error function, or callback function

• Jump to a previous point on the stack via setjmp/longjmp

• Use of assertions to test a state, signal if assertion failed

Some examples of error situations are: truly fatal errors, assertions (we assume that something is OK, and it is not), algorithmic failures (like the dreadful one-off with array elements), and alternate return signals (end of file markers arriving with a file stream for instance). As you can see, these are not all fatal errors or errors at all, but they are exceptional cases which can be handled using exception handling.

The beauty of exception handling lies in not only how it relieves the programmer from handling the exceptional situations explicitly, but also allows increased flexibility in dealing with exceptions. For instance, low-level library code needs to signal information about an exceptional condition to the user interface through intervening library code. Let’s say that a network connection is needed and certain C++ objects need to be created to manage it. One part of the code will try to create the objects. If the object creation leads to an unexpected state (suddenly can’t make the connection), the network object could throw an exception back to the code that tries to use it, and at the same time unwind any partially or fully created objects and other variables on the stack.

Should exception handling should be used to handle all these cases, or should it be used selectively?

Several facts speak in favor of using it liberally. The code is cleaner if the error handling is factored out from the normal flow of execution. Error handling code is reused more often, and the actual function blocks would spend less time dealing with error situations across the board, because the task is delegated to specifically designed exception catch blocks that deal uniformly with error situations. Such catch blocks could provide a uniform way of informing end users about error conditions.

On the other hand, because some runtime environments impose a higher runtime overhead on exception processing than normal execution, exception handling should not be used casually as a way to signal information from one part of the call chain to another, or as a quick and dirty way to implement message passing inside an application.

[Some programmers may disagree with this latter assertion. For instance, it is often useful to use an exception as a means of loop termination when it is easier to detect the termination condition and recover than it is to predict it - such as throwing an EOF exception when trying to read past the end of a file. This has the same effect as a break, but can be done several levels deep in the call chain (as you can with longjmp, but more intuitively). In general, I tend to use a 10:1 rule when using an exception within the normal - if the normal case is executed at least 10 times for each time an exception is thrown then an exception is okay. - sgs]

Why Compiler Support for Exceptions is Better

MacApp, TCL and similar frameworks have implemented specific macros and data structures that provide a way to signal exceptions, provide information about the exception, and indicate that a handler that will catch the exception. In most cases these techniques are built around the ANSI C setjmp and longjmp functions. setjmp saves the current program environment inside a jmp_buf data structure. longjmp will let you jump back to the point saved with setjmp. Think of it as a very smart goto that keeps track of the environment setting.

Macro implementations of exceptions work fine, generally, but there are some known problems. Smart compilers like to optimize variables, stuff them into registers or eliminate them. If this happens, the longjmp back to the earlier point might lead to a situation where things are not the same after all. The solution is to declare variable volatile. This is a way to tell the compiler to keep its hands off the variable. Unfortunately, not all compilers have a working volatile keyword. What MacApp had to do in this case was to create a VOLATILE macro. All this macro does is take the address of the variable, which ensures that the compiler (Cfront in this case) will not place this variable into a register. Modern compilers are still pretty keen on optimizing away variables if they have a chance; hopefully such compilers have a working volatile keyword.

Another issue concerns threads and maintaining a linked list of exception handlers. In many cases we want to have a list of exceptions that are valid (for instance the FailInfo implementation of MacApp). If the application spins off threads, and one of these threads throw an exception, there’s a chance we want to roll back to an earlier state. In such cases we want to yank out the exception structure from the linked list. Now, if we don’t keep track of this case with the thread system (for instance, by creating our own thread dispatcher that will know of such data structures and keep the linked list intact), we might yank out the exception frame from the middle of the list and suddenly the linked list is no longer linked.

Also, if we want to roll back to a known state, and this means that there are objects created that should be destructed, it is really up to the programmer to know about this situation.

This is where a compiler level implementation of exception handling is better. Compilers know about what variables should be kept volatile, what data structures are allocated and when these should be destructed and so on. Dealing with threads case is still a tricky one, though. This is a good example where the platform architecture and the language syntax/semantics are not harmonized. C++ does not go far enough to take care of issues related to threads, and it is the the programmer’s responsibility to be alert about this and similar cases.

C++ exception handling ensures that all class instances will be properly de-allocated off the runtime stack or from the heap. This means that we can now take actions in constructors that can fail because it is possible to return an error result by throwing an exception. If a constructor fails, the de-allocation code is called by the compiler, so that we don’t need to worry about memory leaks and non-allocated objects on the stack. For instance, a constructor could try to create files, and if it fails, the destructor will remove them. In other words, constructors are now far more productive.

Needless to say, C++ exception handling requires runtime support. For normal functions the compiler knows where in a program a function is called, and knows where to pick up execution when the function returns. For exception handling the compiler does not know for a particular throw expression what function the catch block resides in, and where execution will resume from after the exception has been handled. These decisions won’t happen until runtime, so the compiler will leave information around for the proper decisions to take place (generates data structures to hold this information needed during runtime). This means additional overhead in the application execution time, stack size and so on.

Exception Basics, Try and Catch

Someone somewhere will signal that they have an exceptional situation. When an exception occurs, an exception handler is triggered on a higher level, and depending on the situation the handler may do any number of things. It is up to the programmer to indicate where exceptions may occur and should be handled. In the following code, the errors are handled in the block marked with the keyword “try”:

 DoSomething()
 {
    // I’m in trouble
 throw exception;
 }

 try {
    DoSomething();  // This will throw an exception, and the catch
    // below will catch it.
 };

 catch (exception)
 {
    // Ooops, what to do?
 }

So what should we do inside the catch block? We might change something and retry the action, return normally (as nothing really happened), rethrow the same exception with modifications and assume that a higher level catch block will help out, throw a different exception, continue execution to the next statement, or just terminate the program.

When we design applications it is important to define what each layer of the application (from the low level utility functions all the way to the end user level) should do with an exception when exceptions are triggered. Various libraries, such as the new ANSI C++ standard library, include exceptions thrown from various class member functions. It is important that the application will catch any relevant exceptions thrown - assuming that the exceptions are documented, of course. We’ll discuss design issues in more detail later.

C++ Exception Coding, Exception Classes

Here’s a more complex example. We implement exceptions that will throw objects instantiated from classes we’ve defined. Let’s investigate each case one at a time:

 try 
 {
 aFoo = new Foo;
 
 aFoo->DoASillyThing(); //This will throw an exception
 }

Here we will do an initialization of a Foo class, and then call a member function that will trigger an unexpected situation (that was hard coded). The try block will tell the compiler that it should catch any exceptions happening from this exercise.

 catch (...) // catch everything
 {
 cerr <<"We catch every single exception here" << endl;
 }

This is the catch block that is usually programmed after the try case. In this first example we will try to catch every possible exception that is bubbling up from the try case (note the ... notation).

However, in most cases it makes sense to specialize on the exceptions that we want to catch. An exception handler can be written to catch only exceptions of a certain class, or a sub-class. (The classes used in our example are described in the next section.) We write:

 catch (TSeriousMacException &ex) // catch only TSeriousMacException
 {
 cerr << "SERIOUS EXCEPTION: " << ex.GetExceptionMessage() <<  
 ",  OSErr: " << ex.GetExceptionOSErr() <<
 ", File: " << ex.GetExceptionFile() << ",  Line: " <<         
 ex.GetExceptionLine() << endl;

    // Use real Mac UI to signal about the seriousness to the user of the application.
 ExitToShell();
 
 }
 
 catch(TMacException &ex) // catch TMacException
 {
 cerr << "EXCEPTION: " << ex.GetExceptionMessage() << ",       
 OSErr: " << ex.GetExceptionOSErr() <<
 ", File: " << ex.GetExceptionFile() << ", Line: " <<          
 ex.GetExceptionLine() << endl;
 }

    // After the exception is handled, we will continue here (not from where the
    // exception was thrown.)

In the above examples, we catch specific exceptions. Note that these exceptions are objects. Exceptions could be strings (“Help”), integers, and various other data structures. The PowerPlant library uses a less elaborate exception structure that is simply a long. In many cases it makes sense to build an exception class hierarchy (more about this later).

Exceptions are caught in a predefined order, top down, from the specific (sub-class) to the generic. This ordering is important. If you catch a parent class exception before the child one, the child exception is never handled. In this case the TSeriousMacException is handled first, even if it’s inherited from the TMacException class. Note also that we will terminate the application with ExitToShell when the TSeriousMacException is caught, otherwise we will continue if the TMacException is handled.

Note that the execution of the code, after the exception in this particular catch block, will continue on the next code line. The execution of the program does not resume where the exception was thrown. However, the catch block could rethrow the exception to a possible next catch block, as in:

 catch(TMacException &ex)
 {
 throw;
 }

The catch block could also modify the current exception object, or throw another exception object, then the next layer or catch frames will take over (assuming these layers exist). Note also that there will not be a recursion if the same exception object is thrown again, in other words the same exception block is not triggered again.

As shown in the example, the exception objects could contain both member functions and fields. This is handy; when we then throw the exception we could provide information back to the catch block about the situation. As we pass the exception object as a reference, we could modify the object, and pass new information along if we want to rethrow the same exception.

A Little More About Exception Classes

We have defined the exception classes to pass information about the error:

class TMacException 
{
public:
 TMacException(const char *theMessage, const OSErr theError) 
 :
 fMessage(theMessage), 
 fError(theError), 
 fFileName("NO FILE SPECIFIED"), 
 fLineNumber(0L) 
 {};
 
 TMacException(const char *theMessage, const OSErr theError,   
 const char *theFileName, const long theLineNumber)            
 :
 fMessage(theMessage), 
 fError(theError), 
 fFileName(theFileName), 
 fLineNumber(theLineNumber) 
 {};
 
 const char*   GetExceptionMessage(void)     { return fMessage;};
 const OSErrGetExceptionOSErr(void){ return fError;};
 const char*GetExceptionFile(void) { return fFileName;};
 const long GetExceptionLine(void) { return fLineNumber;};
 
protected:
 const OSErr   fError;
 const char*   fMessage;
 const char*   fFileName;
 const long fLineNumber;
};


class TSeriousMacException : public TMacException
{
public:
 TSeriousMacException(const char *theMessage, 
  const OSErr theError) 
 : TMacException(theMessage, theError, "NO FILE SPECIFIED",    
 0L) {};
 
 TSeriousMacException(  const char *theMessage, 
 const OSErr theError, 
 const char *theFileName, 
 const long theLineNumber) 
 :  TMacException(theMessage, theError, theFileName,           
 theLineNumber) {};
};

The TMacException is the base class. This class has fields for storing the OSErr, a string message, file name, line number and it could also contain other various fields. We place these fields into a protected area which is why we need inlined accessor member functions (this is not a requirement, but when we do object oriented design, data encapsulation is a good thing to do anyway).

TSeriousMacException is an interesting class, as it does not really contain any additional fields or member functions. Instead, we pass the values back to the TMacException when we construct the exception class. Why? Well, this was a way to signal that this class is more serious than the normal TMacException, and when we look back at the catch block that catches from specific to more generic exceptions we now have a way to signal priority levels to the catch block.

Throwing Exceptions

So far we have shown both the try and catch blocks, but what about throwing exceptions? Here’s finally the DoASillyThing member function:

void Foo::DoASillyThing(void)
{
 throw TMacException("We did a silly thing", unimpErr, 
 __FILE__, __LINE__);
}

or

throw TSeriousMacException("We did a really serious, silly thing", 
 unimpErr, __FILE__, __LINE__);

What we do is to create an exception object as part of the throw action. We could also do things like:

throw “Help me!”;

or

throw anOSErr;

and then we assume that there’s a catch block that will indeed catch such exceptions, strings or OSErr values (or catches any exception). In this example I wanted to write a flexible exception class that contains as much information about the situation as possible, including possible OSErr values and an information string. The __FILE__ and __LINE__ macros for providing information where the exception was triggered also helps out when debugging C++ code. If typing these variables makes your fingers bleed, here’s a macro:

#define THROWEXCEPTION(name, number) \
 throw TMacException( (name), (number), __FILE__, __LINE__)
 
#define THROWSERIOUSEXCEPTION(name, number) \
 throw TSeriousMacException( (name), (number), __FILE__,       
 __LINE__)

PowerPlant defines similar macros as wrap-arounds for OSErr and NULL pointer tests that will throw an exception if the macro test fails.

Note that the object is constructed at the throw point. This might sometimes not look at the case, as in:

enum MyFailures { noErr, bigErr, semiBigErr};
enum myState = noErr;

{
 throw myState;  // we construct the exception object here, not           
    // before!
}

One problem with constructors and destructors in C++ is that they don’t return any values, so usually you need to implement state information fields inside the class and poll these to know what happened after a constructor or destructor was triggered. Exception handling will now help out, as you could throw exceptions from a constructor or destructor, or:

Bar::Bar()
{
 throw TMacException("Problems inside the Bar constructor",    
 noErr, __FILE__, __LINE__);
}

Remember, exception handling should not be used as a way to signal state directly. Instead this is a way to signal other parts of the code that the constructor never completed fully, so the example above is not fully operational. At the same time any partial object or variable content is also purged by the compiler.

Application Design

It is important to fully define how exceptions are triggered, and what parts of the code will intercept and possibly rethrow the exceptions (using the rethrow key word from inside the catch block) to the next level. If this is not fully architected, it will be very hard to know what was going on inside the code when exceptions are triggered.

If you generate objects as part of the initialization of your application, you should try to catch any exceptions that might bubble up from the classes or any class libraries you are using. After this you still need to install catch blocks inside your WaitNextEvent loop block (in some cases the same catch blocks as mentioned earlier). Then depending on the case you might continue with your event handling (and the application), or terminate the program, and if possible provide the end user a chance to save modified data.

Here’s an example of a simple three-level design using exceptions:

Termination

By default when an exception is thrown, and no handlers exist for the thrown exception, the built-in function terminate is called. In the default behavior terminate will call abort (that terminates the program). That means that you need to include the ANSI C library that specifies abort, or then write your own fake abort, as in:

extern "C" void abort(void);

void abort(void)
{
    // Do whatever it takes, DebugStr or whatever...
 ExitToShell();
}

It makes sense to override this function for more control of what is going on, especially if you are using an external C++ library that will throw both known exceptions (documented) and unknown exceptions (not documented). You could override the default terminate function by using the set_terminate function call (note the correspondence with set_new_handler), as in:


void HandleTerminate(void)
{
 cout << "This is the my own terminate function that I've      
 installed!" << endl;
}

set_terminate(HandleTerminate);

Issues

In many cases you want to recover resources when your function is terminated due to exceptions. One practical way is to tie resource recovery to objects. Such objects could live within the scope of the function, and its destructor is called if this object still exists when the function is terminated due to an exception. Such automatic objects mean that you could do less work inside the catch block. Here’s a simplified example:

 void DoSomethingWithMemory(void)
 {
 try {
 TMemoryBlock myHandleObject; // this might even lock the
    // handle
    
    // Do something that might cause an exception to happen
           // if so the TMemoryBlock object’s destructor is called,
    // memory is unlocked, released and so on.
 }
}

Try to recover from exceptions only if you know you can take a reasonable action to correct the situation. End users won’t like if you catch exceptions and continue with the code, and the system crashes milliseconds later due to a low memory corruption situation, for instance. If you don’t know what really happened, it’s better to rethrow the exception upwards than try a random action that might or might not correct the situation.

You could write extended exception classes that have various options, for instance a debug version will drop you to MacsBug signalling situations, while an end user version will maybe provide an alert, or log status information into a text file.

Summary

I have provided a smaller Metrowerks project and C++ code that shows how the various exception parts work together. Feel free to comment and uncomment code lines in order to learn what is happening.

The Annotated C++ Manual (Ellis & Stroustrup) was the de facto standard concerning the exception handling syntax and semantics. The evolving ANSI C++ standard has today taken over the responsibility concerning standardization. The following URLs are handy for finding the latest drafts:

http://www.cygnus.com/~mrs/wp-draft/
ftp://research.att.com/dist/stdc++/WP/

I would also recommend careful reading of the README files for the various C++ compilers; this various compilers might not implement the full standard at this point of time.

As C++ exceptions are a relatively new feature, we will need to refine how we use exceptions based on more practical experience. Also, MacApp, TCL and other frameworks/libraries have exception implemented using macros, and practicing on these platforms is valuable, and in some cases there might not be a need to rewrite exception handling code just so it conforms to ANSI C++, unless code portability and C++ standard following is a big issue.

References

Ellis and Stroustrup, Annotated C++ Reference Manual, Addison-Wesley.

David Reed, “Using C++ Exceptions”, C++ Report, March-April 1994.

David Reed, “Exceptions, Pragmatic Issues With a New Language Feature”, C++ Report, October 1994.

Booch and Vilot, “Designing with Exceptions”, C++ Report, July-August 1993.

Josee Lajoie, “Exception Handling: Supporting First Class Objects”, C++ Report, June 1994.

Taligent, Taligent’s Guide to Designing Programs, Addison-Wesley.

Think Reference 2.0: Example of a setjmp/longjmp implementation.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Capto 1.2.9 - $29.99
Capto (was Voila) is an easy-to-use app that takes capturing, recording, video and image editing to the next level. With an intelligent file manager and quick sharing options, Capto is perfect for... Read more
Opera 51.0.2830.40 - High-performance We...
Opera is a fast and secure browser trusted by millions of users. With the intuitive interface, Speed Dial and visual bookmarks for organizing favorite sites, news feature with fresh, relevant content... Read more
GarageSale 7.0.13 - Create outstanding e...
GarageSale is a slick, full-featured client application for the eBay online auction system. Create and manage your auctions with ease. With GarageSale, you can create, edit, track, and manage... Read more
1Password 6.8.7 - Powerful password mana...
1Password is a password manager that uniquely brings you both security and convenience. It is the only program that provides anti-phishing protection and goes beyond password management by adding Web... Read more
Evernote 7.0.1 - Create searchable notes...
Evernote allows you to easily capture information in any environment using whatever device or platform you find most convenient, and makes this information accessible and searchable at anytime, from... Read more
MacUpdate Desktop 6.2.0 - $20.00
MacUpdate Desktop brings seamless 1-click app installs and version updates to your Mac. With a free MacUpdate account and MacUpdate Desktop 6, Mac users can now install almost any Mac app on... Read more
HoudahSpot 4.3.5 - Advanced file-search...
HoudahSpot is a versatile desktop search tool. Use HoudahSpot to locate hard-to-find files and keep frequently used files within reach. HoudahSpot will immediately feel familiar. It works just the... Read more
EtreCheck 4.0.4 - For troubleshooting yo...
EtreCheck is an app that displays the important details of your system configuration and allow you to copy that information to the Clipboard. It is meant to be used with Apple Support Communities to... Read more
WhatsApp 0.2.8361 - Desktop client for W...
WhatsApp is the desktop client for WhatsApp Messenger, a cross-platform mobile messaging app which allows you to exchange messages without having to pay for SMS. WhatsApp Messenger is available for... Read more
iClock 4.2 - Customize your menubar cloc...
iClock is a menu-bar replacement for Apple's default clock but with 100x features. Have your Apple or Google calendar in the menubar. Have the day, date, and time in different fonts and colors in the... Read more

Latest Forum Discussions

See All

The best games like Florence
Florence is a great little game about relationships that we absolutely adored. The only problem with it is it's over a little too soon. If you want some other games with some emotional range like Florence, check out these suggestions: [Read more] | Read more »
Angry Birds Champions adds cash prizes t...
Collaborating with developer Rovio Entertainment, GSN Games has released a twist on the Angry Birds formula. Angry Birds Champions features the same bird-flinging gameplay, but now you can catapult Red and co for cash. | Read more »
Around the Empire: What have you missed...
148Apps is part of a family. A big family of sites that make sure you're always up to date with all the portable gaming news. Just like a real family, I guess. I don't know, my mum never told me anything about Candy Crush to be fair. [Read more] | Read more »
The Battle of Polytopia Guide - Tips for...
The addition of multiplayer to The Battle of Polytopia has catapulted the game from a fun enough time waster to a fully-fledged 4X experience on your phone. We've been playing quite a few matches over the past week or so, and we've put together a... | Read more »
All the best games on sale for iPhone an...
Hi there, and welcome to our round up of all the best games that are on sale for iOS at the moment. It's not a vintage week in terms of numbers, but I'm pretty sure that every single one of these is worth picking up if you haven't already played... | Read more »
Disc Drivin' 2 Guide - Tips for the...
We're all still playing quite a bit of Disc Drivin' 2 over here at 148Apps, and we've gotten pretty good at it. Now that we've spent some more time with the game and unlocked more powerups, check out some of these more advanced tips: | Read more »
Alto's Odyssey Guide - How to Tackl...
Alto’s Odyssey is a completely stunning and serene runner, but it can also be a bit tricky. Check out these to try and keep your cool while playing this endless runner: Don’t focus too much on tasks [Read more] | Read more »
Here's everything you need to know...
Alto's Odyssey is a really, really good game. If you don't believe me, you should definitely check out our review by clicking this link right here. It takes the ideas from the original Alto's Adventure, then subtly builds on them, creating... | Read more »
Alto's Odyssey (Games)
Alto's Odyssey 1.0.1 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0.1 (iTunes) Description: Just beyond the horizon sits a majestic desert, vast and unexplored. Join Alto and his friends and set off on an endless... | Read more »
Vainglory 5v5: Everything you need to kn...
Vainglory just got bigger. [Read more] | Read more »

Price Scanner via MacPrices.net

Sale! Amazon offers 13″ 2.3GHz MacBook Pros f...
Amazon has 2017 13″ 2.3GHz Apple MacBook Pros on sale today for $151-$150 off MSRP, each including free shipping: – 13″ 2.3GHz/128GB Space Gray MacBook Pro (MPXQ2LL/A): $1148 $151 off MSRP – 13″ 2.... Read more
Apple AirPods in stock today for $159, free s...
Adorama reports stock of Apple AirPods today for $159 including free shipping, plus pay no sales tax outside of NY & NJ. See our Apple AirPod Price Tracker for the latest prices and stock status... Read more
Saturday Sale: Amazon offers 12″ 1.3GHz MacBo...
Amazon has Silver and Gold 2017 12″ 1.3GHz Retina MacBooks on sale for $250 off MSRP. Shipping is free: – 12″ 1.3GHz Silver MacBook: $1349.99 $250 off MSRP – 12″ 1.3GHz Gold MacBook: $1349.99 $250... Read more
Use your Apple Education discount and save up...
Purchase a new Mac using Apple’s Education discount, and take up to $400 off MSRP. All teachers, students, and staff of any educational institution with a .edu email address qualify for the discount... Read more
Apple Canada offers 2017 21″ and 27″ iMacs fo...
 Canadian shoppers can save up to $470 on the purchase of a 2017 current-generation 21″ or 27″ iMac with Certified Refurbished models at Apple Canada. Apple’s refurbished prices are the lowest... Read more
9″ iPads available online at Walmart for $50...
Walmart has 9.7″ Apple iPads on sale for $50 off MSRP for a limited time. Sale prices are for online orders only, in-store prices may vary: – 9″ 32GB iPad: $279.99 $50 off – 9″ 128GB iPad: $379.99 $... Read more
15″ Apple MacBook Pros, Certified Refurbished...
Save $360-$420 on the purchase of a 2017 15″ MacBook Pro with Certified Refurbished models at Apple. Apple’s refurbished prices are the lowest available for each model from any reseller. An standard... Read more
Amazon restocks MacBook Pros with models avai...
Amazon has restocked 15″ and 13″ Apple MacBook Pros with models on sale for up to $251 off MSRP. Shipping is free. Note that stock of some Macs may come and go (and some sell out quickly), so check... Read more
Lowest price of the year: 15″ 2.8GHz Apple Ma...
Amazon has the 2017 Space Gray 15″ 2.8GHz MacBook Pro on sale today for $251 off MSRP. Shipping is free: – 15″ 2.8GHz Touch Bar MacBook Pro Space Gray (MPTR2LL/A): $2148, $251 off MSRP Their price is... Read more
Apple restocks full line of Certified Refurbi...
Apple has restocked a full line of Apple Certified Refurbished 2017 13″ MacBook Pros for $200-$300 off MSRP. A standard Apple one-year warranty is included with each MacBook, and shipping is free.... Read more

Jobs Board

*Apple* Media Products Commerce Engineering...
# Apple Media Products Commerce Engineering Manager Job Number: 56207285 Santa Clara Valley, California, United States Posted: 26-Jan-2018 Weekly Hours: 40.00 **Job Read more
Digital Platforms Lead, Today at *Apple* -...
# Digital Platforms Lead, Today at Apple Job Number: 56178747 Santa Clara Valley, California, United States Posted: 23-Feb-2018 Weekly Hours: 40.00 **Job Summary** Read more
*Apple* Retail - Multiple Positions - Apple,...
Job Description:SalesSpecialist - Retail Customer Service and SalesTransform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
*Apple* Retail - Multiple Positions - Apple,...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
*Apple* Retail - Multiple Positions - Apple,...
Job Description:SalesSpecialist - Retail Customer Service and SalesTransform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.