Throwing exception when a callback method is available?

stefan posted on Friday, September 21, 2012

Hi Rocky,

I found a code pattern in the CSLA samples (ProjectTracker.Library, V4-3-x) that does look "suspicious" to me.

It is the following asynchronous factory method from ProjectTracker.Library.ProjectGetter:

public static void GetExistingProject(int projectId, EventHandler<DataPortalResult<ProjectGetter>> callback)

Inside the code block you have: if (e.Error != null) throw e.Error;

Shouldn't the callback always be called? The calling context (Typically the UI) should get the chance to react to the exception.

Or maybe there is a reason for the code as it is now, and I just don't get it...

And sorry for the formatting... Embarrassed

JonnyBee replied on Friday, September 21, 2012

You are correct. the code should be:

    public static void CreateNewProject(EventHandler<DataPortalResult<ProjectGetter>> callback)
    {
      DataPortal.BeginFetch<ProjectGetter>(new Criteria { ProjectId = -1, GetRoles = !RoleList.IsCached }, (o, e) =>
      {
        if ((e.Error == null) && (!RoleList.IsCached))
          RoleList.SetCache(e.Object.RoleList);
        callback(o, e);
      });
    }
 
    public static void GetExistingProject(int projectId, EventHandler<DataPortalResult<ProjectGetter>> callback)
    {
      DataPortal.BeginFetch<ProjectGetter>(new Criteria { ProjectId = projectId, GetRoles = !RoleList.IsCached }, (o, e) =>
      {
        if ((e.Error != null) && (!RoleList.IsCached))
          RoleList.SetCache(e.Object.RoleList);
        callback(o, e);
      });
    }
 
Beware that this code will change for CSLA 4.5 to return a Task<T> and also DataPortal_Fetch will return a Task<T>

stefan replied on Friday, September 21, 2012

Hi Jonny,

thanks for the clarification.

The equivalent code pattern can also be found in the code for ResourceGetter as well as in the Exists methods within ProjectGetter and ResourceGetter.

Just search for "if (e.Error != null)" !