Unnecessary creation of an error object which is never used?

[StefanOssendorf]

During my NRT work I've found the referenced code.

csla/Source/Csla.Web.Mvc.Shared/Server/Hosts/HttpPortal.cs

Lines 70 to 78 in c005a93

	catch (Exception ex)
	{
	result.ErrorData = _applicationContext.CreateInstance<DataPortalErrorInfo>(_applicationContext, ex);
	throw;
	}
	finally
	{
	result = ConvertResponse(result);
	}

My understanding is that we create the DataPortelErrorInfo and assign it to the ErrorData property. But the result object is never actually returned. The only "value" is the ConverResponse picks up the error but can't do a thing to influence the program flow.
Should we remove the unnecessary object creation?
It affects the following portals:

• HttpPortal
• GrpcPortal
• RabbitMqPortal

[rockfordlhotka]

I see, the throw means the result is never returned, and the actual ErrorData property must be set at a higher level in the workflow on the server.

So yes, this is probably a useless catch due to some change that occurred over time and left this code behind.

[StefanOssendorf]

Or the throw has to be removed. I'm not sure if the finally block is in a case of an exception obsolete, too?
A user can "ConvertResponse" to something that's entirely ignored.

[rockfordlhotka]

When this is addressed, whoever does the work needs to look at the higher level and see how (and if) the error info is created, and ensure that the ConvertResponse is invoked in some manner. That's the hook for compression or encryption or whatever someone would want to do to the byte stream.