Remove DFATAL from folly::Singleton::try_get()

Summary: try_get() API is confusing right now, because it returns nullptr in release, but crashes in debug build. Users end up handling nullptr returns, yet their code crashes in debug builds for no reason. See https://www.facebook.com/groups/fbthrift/permalink/1222120054481561/ for an example.

If we want to keep the crashing API we should probably name it differently and make it crash both in debug and release.

Reviewed By: dhruvbird

Differential Revision: D2587818

fb-gh-sync-id: 5834bfa08eb5d9bc6db1c5edf4a048a5b1d3212c

diff --git a/folly/Singleton.h b/folly/Singleton.h
index 194eb6b462e7e0f6f83ed4577c86f24ae2ee37af..94867c02f9f456e4aafa55dde7c1b203f7a3bf14 100644 (file)
--- a/folly/Singleton.h
+++ b/folly/Singleton.h
@@ -494,15 +494,11 @@ class Singleton {
   // stored; a singleton won't be destroyed unless shared_ptr is destroyed.
   // Avoid holding these shared_ptrs beyond the scope of a function;
   // don't put them in member variables, always use try_get() instead
+  //
+  // try_get() can return nullptr if the singleton was destroyed, caller is
+  // responsible for handling nullptr return
   static std::shared_ptr<T> try_get() {
-    auto ret = getEntry().try_get();
-    if (!ret) {
-      LOG(DFATAL) <<
-        "folly::Singleton<" << getEntry().type().name() <<
-        ">::get_weak() called on destructed singleton; "
-        "returning nullptr, possible segfault coming";
-    }
-    return ret;
+    return getEntry().try_get();
   }
 
   explicit Singleton(std::nullptr_t _ = nullptr,