function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Why do a try-catch (typeException) in this trigger? How to test for that?

I am in the process of cleaning up some code written by a consultant. Much of it is neither documented or well commented.  I'm tasked with removing code that isn't used (there has been a ton of it, so far), generally cleaning up the code that's left, bringing the org test coverage up (somehow, they managed to get us down to < 72% coverage), and documenting all of it for our sustaining engineering group.


Here is a trigger that's baffled me:


trigger copyAccountOwnerBIBI on Account (before insert, before update) {
   for (Integer i=0; i <; i++) {
      Account a =[i];
      try {
         if (a.OwnerIdCopy__c==null || a.OwnerIdCopy__c != a.OwnerId) 
            a.OwnerIdCopy__c = a.OwnerId;
      catch (TypeException e) {
         a.OwnerIdCopy__c = null; 


Ok, I get what the trigger is supposed to do: copy the account.OwnerId field into the OwnerIdCopy__c field. 


Here's what I don't get:


What are the cases in which a TypeException error might be thrown by this trigger?  I can't think of any, an am tempted to just remove the try-catch altogether, but hoping someone in the dev community will chime in with, "No, dummy, here's why you need that ...". 


If it is needed, what would a test method for that try-catch look like?  Thoughts?


The documentation states that a TypeException occurs when an error occurs converting data from one type to another. Assuming OwnerIdCopy__c is a lookup to a user, and OwnerId is the same type, this exception should never occur. Standard system validation, such as preventing assignment to an inactive user, should eliminate any possibility of this exception occurring. The only thing that I would possibly even imagine causing this exception would be an invalid user type being assigned to the field (maybe one of the pseudo-user types, such as a customer portal license?). In any event, I think that the scenario would be overwhelmingly small that such an exception would occur, and without knowing how such an exception might occur, there's certainly no way to write a test method for it. Personally, I would remove the exception handling, and if you receive a failure notification about it, then you could document why that exception handler is required and put the code back in place. And feel free to post that reason here on this thread, since I too am curious as to why anyone would need to catch a TypeException here.


Random thought... One could also ask the question:  Why is this trigger even needed?


I mean, if *all* it does is guarantee that the Copy field is *always* the same as the original OwnerId field, why not just blow it away and change other references to use the original field.


Why is that field there in the first place?   That might lead to an understanding of why there might be problems on the assignment (perhaps if there are permission violations?)


But, I agree, I don't see why catching the Type exception makes any sense.    -Steve


The usual reason why any organization even has such a trigger is typically due to a limitation of formula fields. That limitation is that you can not navigate the OwnerId relationship, but you can navigate a custom user lookup field.


For example, given a custom formula field with this formula (won't save if you try):



IF(Owner.UserRole.Name='Customer Service','CS-User','Not CS-User')

This formula simply won't work, claiming that the Owner field does not exist. There's simply no way to reference anything other than the OwnerId of a record.



If you copy the OwnerId into a user lookup field, the formula becomes valid:



IF(OwnerIdCopy__r.UserRole.Name='Customer Service','CS-User','Not CS-User')


This method has been used as long as there has been a need to navigate the owner relationship which has been mysteriously excluded from relationship navigation in formula fields.


The only theoretical cause for an assignment violation should be the event that the user was inactive. However, because of standard constraints in the system, this trigger will never assign an inactive user into this field. Namely, you can not edit a record owned by in inactive user, and you can not assign a record to an inactive user, and this trigger is a on-change type (it only does an action if the owner is not the same as the previous edit), so the only qualifying edit that could possibly occur would be to assign a valid, active user into the copy field, which should never raise an exception.