[Mac] Allow NSExceptions in certain cases.

printing/printing_context_mac.mm

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "printing/printing_context_mac.h"
 
 #import <ApplicationServices/ApplicationServices.h>
 #import <AppKit/AppKit.h>
 
 #include "base/logging.h"
 #include "base/mac/scoped_cftyperef.h"
+#include "base/mac/scoped_nsexception_enabler.h"
 #include "base/sys_string_conversions.h"
 #include "base/values.h"
 #include "printing/print_settings_initializer_mac.h"
 
 static const CFStringRef kColorModel = CFSTR("ColorModel");
 static const CFStringRef kGrayColor = CFSTR("Gray");
 
 namespace printing {
 
 // static
 PrintingContext* PrintingContext::Create(const std::string& app_locale) {
   return static_cast<PrintingContext*>(new PrintingContextMac(app_locale));
 }
 
 PrintingContextMac::PrintingContextMac(const std::string& app_locale)
     : PrintingContext(app_locale),
       context_(NULL) {
 }
 
 PrintingContextMac::~PrintingContextMac() {
   ReleaseContext();
 }
 
 void PrintingContextMac::AskUserForSettings(gfx::NativeView parent_view,
                                             int max_pages,
                                             bool has_selection,
                                             PrintSettingsCallback* callback) {
+  // Third-party print drivers seem to be an area prone to raising exceptions.
+  // This will allow exceptions to be raised, but does not handle them.

[stuartmorgan, 2011/05/17 18:52:14]

I don't understand. Why would we *deliberately* allow exceptions to blow through
C++ stacks, when we know that will cause weird crashes we won't understand? This
seems like the worst possible behavior.

[Scott Hess - ex-Googler, 2011/05/17 19:34:40]

The primary benefit of making NSExceptions fatal is that it gives us fast
turnaround when _we_ write bad code.  My short-term goal is to get as many
exceptions fatal as possible for as much of the code as possible.  As my TODO
indicates, it's not entirely clear to me how we can generically deal with the
issue in this case, but it is pretty clear that the printing subsystem is one
area where we see exceptions that we aren't (apparently) at fault for.

If the sub-system is handling them correctly, then this change is a reasonable
change.  If not, we'll still need to track down why they are being raised and
what a reasonable way to address it is (I'm sure that will be FUN!).

+  // TODO(shess): Some experimentation indicates that uncaught exceptions can
+  // leave the print panel up, and any use after the exception will almost
+  // certainly crash on access to zombie objects, but simply _catching_ the
+  // exception doesn't resolve the problem, because you cannot easily dismiss
+  // the print panel from code.  This situation doesn't seem right, to me.
+  base::mac::ScopedNSExceptionEnabler enabler(true);
+
   DCHECK([NSThread isMainThread]);
 
   // We deliberately don't feed max_pages into the dialog, because setting
   // NSPrintLastPage makes the print dialog pre-select the option to only print
   // a range.
 
   // TODO(stuartmorgan): implement 'print selection only' (probably requires
   // adding a new custom view to the panel on 10.5; 10.6 has
   // NSPrintPanelShowsPrintSelection).
   NSPrintPanel* panel = [NSPrintPanel printPanel];
@@ skipping 306 matching lines @@
 void PrintingContextMac::ReleaseContext() {
   print_info_.reset();
   context_ = NULL;
 }
 
 gfx::NativeDrawingContext PrintingContextMac::context() const {
   return context_;
 }
 
 }  // namespace printing