Joshua Napoli

My previous post explained the need to provide debugging context with C++ exception objects and provided an easy way to manually incorporate arbitrary pieces of context. An interesting suggestion is to incorporate a stack trace into the exception. This time, I’ll look at exceptions in a multi-threaded environment.

Termination style exceptions trace back to the notion of the “undefined” symbol in abstract functional programming. Any expression containing the undefined symbol evaluates to the undefined symbol. In C++, an “expression” is meticulously assembled on the stack. A throw statement is tantamount to dropping the undefined symbol into the expression embodied by the stack. Instead of simply reducing to a single symbol, the throw statement maps to a new expression (beginning with the catch statement) through the following steps:

1. squirrels away an arbitrary piece of state, pushing it onto the exception stack,
2. abandons the partially evaluated expression embodied by the current call stack,
3. and then evaluates a sequence of catch handlers.

Real applications are multi-threaded. Even if side effects are successfully managed in our C++ code, the program-is-an-expression model is not adequate anymore. We have to consider how an exception in one thread should relate to the execution of the other threads of the system.

Many multi-threaded scenarios can be mapped onto the “futures pattern”. A primary thread initiates an asynchronous action and retains the option to retrieve a result at a later time, through a proxy object that represents a “future” value. In this scenario, the correct behavior is obviously that an exception be transfered from the asynchronous actor back to the primary thread when it attempts to retrieve the actual “future value”.

Thus, we want a mechanism to transfer and continue the cancellation action of an exception from an asynchronous actor to a primary thread. This transfer is passive, meaning there is a phase after the exception passes out of the asynchronous actor and before it enters the primary thread. (It is interesting to note that Haskell has an active “throwTo” transfer mechanism where a perpetrator thread can asynchronously inject an exception into a victim thread.)

Now - back to C++’s state squirreling. Our exception is held just outside the reach of the “catch” statement. We can only see the slice of it that corresponds to the catch declaration. This presents a bit of a problem when we try to implement something that transfers the exception between threads. The “re-throw” feature lets us transfer the hidden exception state between catch handlers within a thread. However, there is no mechanism that can either completely reveal the hidden state or transfer it to a second thread.

C++09 will solve this problem by adding a handful of functions to retrieve and manipulate an opaque pointer (exception_ptr) to a thrown exception.

Of course, we need this to work in 2007. The simplest approximation of the exception_ptr system is to add a “cloneable_exception” base class with “clone” and “rethrow” virtual functions. However, this approach does not address exceptions thrown from 3rd party libraries. It builds in a kind of obscolescene, since the cloneable_exception base class will be unnecessary once we move to C++09.

C++ exceptions are a distraction. They foil the debugger and they diffuse our attention from the predominant control flow of the software. At point where we throw these exceptions, we usually don’t have enough context to distinguish static programming bugs from dynamic errors. Since our tools aren’t quite as handy with relating exceptions to the underlying programming bugs, the exception seems to get in the way of the debugging effort. We can only see a slice of the exception object. The (Microsoft) debugger is inconsistent about where it breaks when an exception is thrown (for caught versus uncaught exception).

Last week, another developer and I spent a total of four developer-hours hunting down a problem. A couple of exceptions were being thrown. As it turns out, I had mistyped a directory name, which caused boost::filesystem to emit an error in my graphics thread. This in turn caused some collateral damage to a communication process in a different thread - perhaps a timeout due to some interference from the debugger. The debugger tripped on the communication thread before the filesystem error. We noticed the exception, but the filename did not appear in the “what” text of the filesystem error. So, the code-review concentrated on the more complicated communication thread first, wasting a lot of time. If only the filesystem library could have noted the filename in the “what” text, then we could have avoided the extra work.

This little wrong-turn led me to look for a better way of organizing exceptions. C++ exceptions protect our routines from violating their postconditions. They give a routine the chance to “give up” - to surrender the responsibility of coping with a particular input. Of course, for the developer, exceptions are a relatively poor debugging tool. The problem is that they only carry a small fraction of the information that the debugger would be able to provide. Even when the exception carries the appropriate information, it can be difficult to access. For example, my filesystem exception carried a filename field, but the filename did not carry through to the
“what” message. At this early stage of the project, the “what” text is dumped to a debug window, but there are not yet specializations for the many types of exceptions that could wind up falling into my error handler.

An exception object really has two significant responsibilities:

1. Pass sufficient information about the context of the error back to the exception handler so that it can retry or a useful message can be sent to the user.
2. Make enough information available to the developer to debug unanticipated exceptions.

We are all used to dealing with the first point. Since arbitrary data can be carried by the exception object, it is easy to meet the requirement. My troublesome filesystem error certainly contained everything that the user needed to know. However, the second point is quite open-ended. We surely do not want to embed a fully featured debugger in our exception handler. On the other hand, it would sure be nice if a whole lot of the context of the exception were carried.

One way to address the issue is to make an exception object that is trivial to add information to, and everything is exposed through the “what” message. For example,

 throw error() << boost::error_info<filename_tag>(path);

There are a couple of problems with the approach. First, the identity of the fields inserted to the stringstream are lost. When my application is all grown up, a filesystem exception will cause a dialog box to open or trigger a search process. In either case, the path in question will need to be interpreted, and extracting it from the human-readable string is going to be annoying.

Second, the stringstream copy constructor and insertion operators can throw bad_alloc. If the copy constructor throws while the exception is being propagated (and not caught before the end of the function), then terminate() will be called. If the insertion operator throws, then the original exception will be lost. David Abrahams warns against embedding std::string objects or formatting before the call to what() for these reasons.

Here is an abbreviation of David Abrahams’s guidelines for exception classes for the boost library:

1. Derive your exception class from std::exception.
2. Use virtual inheritance.
3. Don’t embed a std::string object.
4. Format the what() message on demand.
5. Don’t worry too much about the what() message.
6. Expose relevant information about the cause of the error.
7. Make your exception class immune to double-destruction.

Items 1 and 2 are addressed with some trivial syntax (make the stringstream a member of a class that inherits from std::exception). It’s worth noting that we are attacking the basis of item 5; in fact our goal is to get enough information in the basic exception object to reduce the need for the debugger. Item 7 can probably be solved using a custom allocator.

Items 3, 4 and 6 are non-trivial to address. There is no built-in way to delay the formatting of an arbitrary list of stream insertion operations. More importantly, there is no easy way to identify fields within the formatted string. The complexity of any attempt to delimit fields in the text string seems to be out of line with the relatively small scale of the problem.

Emil Dotchevski has proposed a library for boost that addresses the basic problem of easily recording arbitrary data fields in an exception object. Here is a before and after example.

Standard exception

 struct error : std::exception {   setFilename(const filesystem::path&);   const filesystem::path& getFilename() const;   const char* what() const; }; void f(boost::filesystem::path path) {   error e;   e.setFilename(path);   throw e; }

With Dotchesvski’s boost Exception proposal:

 struct filename_tag : error_info_value {}; struct error : boost::exception {}; void f(boost::filesystem::path path) {   throw error() << boost::error_info<filename_tag>(path); }

The library is successful at eliminating boilerplate implementation of what and getters/setters. It is well suited to situations where errors can be complex. For example, OpenGL can report a vector of error flags, and there is even the possibility of a flag having multiplicity greater than one. While it is possible to build this field into the type of the exception, it appears to be counterproductive. Microsoft Visual Studio 8 usually describes such a complicated exceptions as having an “unknown type” (although the correct catch clause does get invoked). OpenGL error flags could be easily encoded in the fields of Dotchevski’s library.

Nevertheless, our desire is to make it easy for the library designer to expose the widest variety of details of the context of the error. We expect a wider variety of details to be relevant for debugging than would be required to determine messages for the end-user. While Dotchevski eliminated the boilerplate code that would normally be required for transmitting predefined fields, he does not let the programmer easily add ad-hoc bits of context.

Some people would prefer to use the “what” message as a key to the exception type. The string could serve as a key to a table of user error messages or otherwise provide the fine-grained choice of action. The catch stage of exception filtering is then a more coarse filter. However the typeid operator can be employed for the same purpose, freeing the “what” message for use as a debug stream.

I developed my own exception class to make it as easy as possible to add data to the exception object. The source code is available here. It uses an ostream syntax that can accept any object that is copyable and has a ostream inserter. Here is the basic interface:

 class exception { public:   virtual const char* what() const throw();   void visit(const error_info_visitor_base& v) const;   template void set(const T&t) const;   virtual ~exception() throw(); }; template<typename E, typename F> const E& operator<< (const E& e,const T& t) {   e.set(t);   return e; }

It is the same as std::exception, with the addition of set and visit member functions and an insertion operator. The set member function adds an object to a list of data elements. The visit member function applies a visitor to each data element whose type is compatible with the visitor. To help the error handler get data out of the exception object, there are helper functions for constructing an error_info_visitor class:

 unspecified_type on_error_info(Tag, F f) {   return error_info_field_visitor<error_info&ltTag>,F>(f); } unspecified_type on_error_info(F f) {   return field_visitor<F>(f); }

Here is an example where an exception is thrown, and a data element is added and extracted.

 try {   throw exception() << 5 << "Hello World"; } catch(exception&e) {   using boost::lambda::_1;   using boost::lambda::var;   int i(0);   e.visit(boost::on_error_info<int>(var(i)=_1));   cout << i << "\n"; /*prints "5"*/   cout << e.what() << "\n"; /*prints: "5Hello World"*/ }

At the throw site, the data values are simply recorded. String formatting is not done until the what member function is called.

Often, we need to “translate” exception types in order to better describe the context of the error. My exception class allows the data elements from the first to be inserted into the second exception object. Here is an example:

 class system_error : public boost::exception {   int errno_; public:   explicit system_error(int err=0) : errno_(err) {}   int& err() {return errno_;} }; void f() {   try {     try {       throw boost::exception() << 9 << " hello ";     }     catch(boost::exception&e) {     throw system_error(2) << e;   } } catch(system_error&e) {   using boost::lambda::_1;   using boost::lambda::var;   int i(0);   e.visit(boost::on_error_info&ltint>(var(i)=_1));   cout << i << '\n'; /*prints '9'*/   cout << e.what() << '\n'; /*Prints "9 hello world"*/   cout << e.err() << '\n'; /*Prints '2'*/ }

In the next post, I’ll show how to emulate part of the new C++0x support for “saving exceptions”.

Julie and I recently visited Mass Moca to see the Spencer Finch exhibit, What time is it on the sun?. Finch’s work strove to reproduce elements of sensory experience removed from their natural context. For example, in “Two Hours, Two Minutes, Two Seconds,” a bank of fans reproduced the variations of the gentle breeze at Walden Pond at a particular time period. In other works, the mood of the museum was altered by the indirect light from pieces that reproduced the light of the sky or the ground at specific locations and times. “Sunlight in an Empty Room” is shown on the right. It reproduces the color of the light in the home of Emily Dickinson as a cloud passes by. The macroscopic context was always obliterated within the piece. However, the exhibition guide recovered the context and its descriptions became an integral part of enjoying the work.

Julie’s first body of work has a similar notion. She visually separates the gestalt of natural objects from particular symmetries, graphic forms or textures.

We found Finch’s “Night Sky…” particularly inspiring. The bulbs hung from the ceiling are connected to describe the molecular structure of pigments that might be used in a painting of the Arizona sky on a particular evening. Finch’s meta-metaphor is fun, but I’m content just to put some interesting lights on our ceiling. The plan is to cover a meandering patch of our eat-in kitchen with light bulbs.

I decided that a relatively dense packing of G40 and G25 bulbs, would look nice. Finch used bulbs with curly filaments, but I’m not sure where to get them. The bulbs will hang by their wires from hardboard panels. Tubular white appliance wire would probably look better than the clear/copper wire that I used. I found the porcelain sockets that Finch used at Home Depot, and Julie used hot-glue to make a kind of strain-relief so that the weight of the bulb is supported by the casing of the wire, rather than the electrical connections (in retrospect, hot glue is probably a poor choice of material to use around a hot bulb).

Each panel is 16×20″ and should hang ten to twenty bulbs. The panels will let me build and install the project in a modular way and hopefully without permanent damage to the ceiling. It’s actually kind of hard to arrange the bulbs “by hand”. They are fragile, and the wires like to tangle and flop around. So I modeled the bulbs and wires in Mathematica and set to work making an energy function whose minimization would give a nice bulb arrangement. The first experiment used ten bulbs. That’s a lot of degrees of freedom, but with some difficulty I managed to coax the built-in numerical minimization engine to give a reasonable arrangement. I will probably need to write my own optimization algorithm to solve a larger number of bulbs. Based on the plan determined by the minimization function, I drilled the holes in the hardboard and used heat-shrink tubing on the wires to the bulbs to set their length. Julie tried replacing the globe-style bulbs with cylindrical ones. It could look interesting (a stubby version of Sina’s “The End of the Red Line” of the Alewife MBTA station), but it would end up being more expensive.

We’ll paint the panel white (better to do this before stringing the wires!), but it looks good. The clear casing on the wire is a bit too stiff; I want the bulbs to hang straight down.

I first learned of Synthetic Aperture Photography at SIGGRAPH 2004 at Levoy’s paper session “Synthetic Aperture Confocal Imaging”. The idea is to integrate an array of discrete apertures into a larger, simulated aperture. The paper was actually about macroscopic confocal imaging using a bank of projectors to simulate an illumination system with a very large aperture. Since the illumination gets the wide aperture, off-focal-plane objects are dim and don’t reduce the contrast of the final image as much as for imaging performed with a simulated aperture on the camera. I didn’t have the luxury of illuminating the neighborhood with a bank of projectors, so you can see that my synthetic aperture shots have reduced contrast where the background is partially occluded.

To get this demo done in a day, a made a few simplifying assumptions. The camera model is linear, the camera translates at a constant rate along a line, and the synthetic focus is parallel to the imaging plane. Assuming all that, there is almost nothing left to do: the result is a sum of shifted images, scaled by the number of contributors. The shift is a function of the distance to the focal plane. (Google needs to make some simplifying assumptions with their video processing… it took longer for a few frames of video to be prepared for posting than for me to do the entire project.)

I transferred the video from my cell phone to Julie’s MacBook over Bluetooth and coded up the shift-and-sum in Mathematica. Autocorrelation gave some hints as to good focal planes. I made a variation of the shift-and-sum to allow the focal plane to be “programmed”. Here is N. Broad Street in Milford, CT, imaged at street level. The street is actually lined with cars that occlude parts of the source video. The image will be sharper when I add a function to tilt the focal plane.

Hwang et al. proposed a variation on synthetic aperture photography using a microlens array to produce multiple apertures with a single, stationary camera. The SIGGRAPH paper also considered autostereoscopic displays for generating the synthetic aperture light field, which amounts to the same technique.

On Sunday, I made a synthetic aperture demo to remove foreground objects from a street side video stream. I had Julie drive at a constant speed down North Broad Street in Milford, CT as I captured a video with my cell phone. The image quality of the refocused image could be improved by setting the focal plane more carefully. I made a video to show the comparison of the captured against refocused, but Blogger.com is choking on it right now. I’ll show some individual frames instead. Here are a couple of examples of foreground occluders being removed:

The strong, static system of C++ seems to provide almost everything that the weak and dynamic type systems of Perl and Python do, but also adds an extra, automatic error checking step. It’s a bit perplexing as to why C++ seems to fail to provide overall advantages in development efficiency or extensibility. The failure can be attributed to extra development cost to maintain parallel type calculations throughout the software and also to the failure of type checking to provide a sufficiently broad proof of the program’s self-consistency.

In order to compile, the types must be consistent. Unfortunately, as C++ currently stands, the majority of this consistency checking falls in the hobgoblin category. The software developer must redundantly calculate the result type of almost every expression. This is a useless exercise that adds no information to the program (the compiler independently calculates the types anyway). In some cases the return type of a function is considered an implementation detail that should not be exposed to the application design (for example, boost::bind). Here it is impossible (or at least detrimental) to reflect the return type. This makes a noticeable reduction in the expressive power of such libraries. C++ 0x may help with auto and valtype keywords. Since the “initializer expression” may not be readily available for class member variables, these keywords will add some asymmetry between state variables and scoped variables. One should probably think of scoped variables as descriptive names for subexpressions of a function rather than simple values.

The compiler’s verification that the types in the software are consistent should give an indication that the software is to some degree correct. Evidently, that is not the case as C++ software needs essentially the same testing regimen that weaker languages do. Two aspects of the language contribute to the disappointment in C++ software robustness. First, the standard library offers no assistance. For example, there is no “type qualifier” mechanism for doing things like dimensional analysis or taint analysis. Without library support, it is difficult to make use of the type system for verifying any non-trivial degree of consistency within the program. The second factor is the asymmetry between types and values. Although most test cases could be evaluated statically, there is no way to induce the compiler to make the evaluation and assert an error on failed test cases. Without this integration, software development organizations must invest in a substantial infrastructure to organize, compile, and execute specialized testing projects.

At a higher level, the case of program validation with C++ could be vastly improved if it had some facility for introspection and pattern replacement on its abstract syntax tree. It’s hard to understand how any modern language fails to provide this bit of introspection. One would like to inject new rules into old software: for example, to deal with instances of ‘new’ where the result is not immediately assigned to a smart pointer (replace the raw pointers to shared pointers or issue errors). Presumably you will learn more interesting and powerful practices in the future that would be beneficial to apply to the code that is being written today.

Integration of the abstract parse tree with the code editor opens up some interesting possibilities. For example, pattern replacement operations in the previous paragraph could be represented within the editor. At SciFoo Camp, Charles Simonyi and Ted Kaehler both described work on development environments that would have the ability to render different views of some underlying syntax tree. UML has similar ideas, but in UML the focus is on integrating different levels of abstract design rather than elucidating the implicit relationships within an actual piece of software.

Skippers Dock
60 Water Street
Stonington, CT

The restaurant has outdoor seating on a dock overlooking the picturesque bay. The food did not live up to the standard set by the view, and we expected more based on the price. Our appetizer, drinks and dessert cost $80, but none of the dishes showed any evidence of creativity and most could have benefited from more skillful preparation. For waterfront dining, S&P Oyster in Mystic is a better choice. It had better food and lower prices.

Up River Café
37 Main Street
Westerly, RI

My wife and I are fans of Up River Café. The restaurant is built over part of the river in downtown Westerly, Rhode Island. There is a patio that overlooks the river, for al fresco dining. We always enjoy the patio, although there are a few mosquitoes after sunset. The two of us spend about $130 for a dinner with a glass of wine and a desert. Dinner has always been good and the river ambiance makes for a nice evening.

Most recently, I had a swordfish dish with polenta and a red pepper coulis, topped with fennel. Other restraints (such as Legal Seafoods) will serve instant “polenta” partially disguised, but at Up River the polenta was made properly, preserving the milled corn taste to contrast with and slightly sweeten the fish. The sauce and vegetable topping were perfect. My wife had striped bass with artichoke hearts, purple fingerling potatoes and red pepper coulis. The swordfish dinner was more interesting and flavorful than the striped bass.

My wife liked the prickly pear sangria, although the portion was quite small, since the wine glass was mostly full of ice.

S&P Oyster
Mystic, CT
206-911-1343

In the summertime, I sometimes annoy my wife by going to extraordinary lengths to find waterfront al fresco dining. Even in Mystic, CT, a place intimately tied to the sea, there are surprisingly few options for a nice dinner on the water. This scarcity is an advantage to the owners of S&P Oyster, a nice restaurant situated at the end of the famous drawbridge. On Labor Day weekend, the place was packed, of course. My wife and I waited an hour and a half for a seat on the outdoor patio. The view of the river was nice. The operation of the bridge and the constant stream of humanity crossing it provided some entertainment. Dinner was reasonably priced, although unexceptional. For $70, we each had an appetizer and dinner, and we split a desert. The salmon was tasteless. You may want to skip the scallop and proscuitto dish on the “lighter fare” menu. The proscuitto in the dish is too salty.

The Patio
http://www.ptownpatio.com/
Provincetown, MA

On Thursday, my wife and her parents had gone down to Cape Cod for a long weekend. I had business in Boston on Friday, and so I came afterwards. I took the ferry to meet my family in Provincetown. It was Julie’s mother’s birthday, so we decided to take her out for dinner. We walked down the street looking for a suitable place and settled on “The Patio”. Indoors, the restaurant was too noisy for us, so we ate outside. The tomato and mozzarella salad was quite good, but the crab-cake dinner was marginal. My wife’s macadamia nut encrusted chicken dinner was really good. The restaurant generally seemed worth a second visit.