Issue #1234 - std::wstring version of UnescapeUrl

src/plugin/PluginClientBase.cpp

Index: src/plugin/PluginClientBase.cpp
===================================================================
--- a/src/plugin/PluginClientBase.cpp
+++ b/src/plugin/PluginClientBase.cpp
@@ -66,6 +66,38 @@
   return url;
 }
 
+void UnescapeUrl(std::wstring& url)
+{
+  /*
+   * When the code can tolerate exceptions better,
+   *   there's no reason to keep this try-catch statement in place.
+   */
+  try
+  {
+    DWORD result_length = INTERNET_MAX_URL_LENGTH;
+    /*
+     * The buffer length is greater than 2 Kb, so we keep it off the stack and allocate it.
+     */
+    std::unique_ptr<wchar_t> result(new wchar_t[result_length]); // can throw bad_alloc

[sergei, 2014/08/05 12:53:04]

It's better to use `std::unique_ptr<wchar_t[]>`.

[Eric, 2014/08/05 13:09:10]

Yep. Missed that one.

+    /*
+     * Casting away const here is harmless because we're not using the in-place modification mode of UrlUnescape
+     */
+    HRESULT hr = UrlUnescapeW(const_cast<wchar_t *>(url.c_str()), result.get(), & result_length, 0);

[Oleksandr, 2014/08/05 12:20:58]

Nit: no space after &

[Eric, 2014/08/05 17:53:01]

Done.

+    if (hr == S_OK)
+    {
+      url = std::wstring(result.get(), result_length);
+    }
+    /*
+     * If the call to UrlUnescape fails, we don't alter the string.
+     * This matches the behavior of the previous version of this function.
+     * Because there's no error handling, however, this masks failures in UrlUnescape.
+     */
+  }
+  catch(...)
+  {

[Oleksandr, 2014/08/05 12:20:58]

I personally am very cautious with empty catch-all exceptions. Maybe at least
let's log something here?

[sergei, 2014/08/05 12:53:04]

+1 here.
Each time such all exception eating construction looks very dangerous.

I've seen Eric's comments above in the code. Let's create a ticket to make a
plan what we need and what we understand under the maintenance of this code. If
there is no big plans of evolving of the code, then it could be OK.

[Eric, 2014/08/05 13:09:10]

Look, I agree with both of you. I do not like blanket suppression of exceptions.
In the present case, however, it is acceptable as an interim measure. At the
worst, it has the same behavior as the previous version of this code, which is
to leave the URL unchanged.

In the general case, if you catch bad_alloc, it's generally time to gracefully
shut down the application or something related. We don't have such a mechanism
other than std::terminate, which would shut down IE as a whole.

I added a ticket such as Sergei wants yesterday.
#1173 Ensure that C++ exceptions do not propagate out of entry points
https://issues.adblockplus.org/ticket/1173
I did a bit of code audit to identify most (probably not all) of the places we
need it. This isn't the entirety of what we need for this task, admittedly. Some
kind of unified logging would also be appropriate. Nevertheless, if it were safe
to throw exceptions in the current code base, I would have left out the
exception handler entirely; bad_alloc is unusual enough that it could be handled
at the top level.

+    // no modification if exception
+  }
+}
 
 void CPluginClientBase::LogPluginError(DWORD errorCode, int errorId, int errorSubid, const CString& description, bool isAsync, DWORD dwProcessId, DWORD dwThreadId)
 {