Background

When it starts up, the CKAN GUI adds support for ckan://identifier URLs on Windows and Linux.

On Windows, it does this by adding this registry key:

CKAN might need to escalate privileges to make these changes. It detects this after the fact by catching an UnauthorizedAccessException when it attempts to set the registry key. If this exception is thrown, ckan.exe re-launches itself as administrator with the registerUrl command line flag, which prompts the user whether to allow the increased privileges and then sets the registry key.

Problem

The user might see this error when launching CKAN:

8468 [1] ERROR CKAN.URLHandlers (null) - There was an error while registering the URL handler for ckan:// - Cannot delete a subkey tree because the subkey does not exist.
8485 [1] ERROR CKAN.URLHandlers (null) -    at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at Microsoft.Win32.RegistryKey.DeleteSubKeyTree(String subkey, Boolean throwOnMissingSubKey)
   at CKAN.URLHandlers.RegisterURLHandler_Win32()
   at CKAN.URLHandlers.RegisterURLHandler(Configuration config, IUser user)

If this is fixed, other errors can appear:

12186 [1] ERROR CKAN.URLHandlers (null) - There was an error while registering the URL handler for ckan:// - Cannot write to the registry key.
12200 [1] ERROR CKAN.URLHandlers (null) -    at System.ThrowHelper.ThrowUnauthorizedAccessException(ExceptionResource resource)
   at Microsoft.Win32.RegistryKey.EnsureWriteable()
   at Microsoft.Win32.RegistryKey.DeleteSubKeyTree(String subkey, Boolean throwOnMissingSubKey)
   at CKAN.URLHandlers.RegisterURLHandler_Win32()
   at CKAN.URLHandlers.RegisterURLHandler(Configuration config, IUser user)

Causes

The DeleteSubKeyTree call doesn't throw UnauthorizedAccessException when it can't do its job as we would hope. So this call should have its exceptions caught and ignored just like the lines above it.

But if UnauthorizedAccessException is thrown, it's re-thrown after it is caught and handled:

This is redundant, because no other code is going to be able to do anything more to help the situation than has already been done, and if the privilege-escalated sub-process is able to set the key, then the user has no reason to care about this exception.

Changes

Now DeleteSubKeyTree is called within the try block above its current location, and we don't re-throw any UnauthorizedAccessExceptions. This prevents the error message from bothering the user.

Fixes #2362.