4

I have gone through at least 10 sites explaining the use of this. What I cannot ascertain is if I simply want to try something and if it fails, go on (don't need to do anything with the error). I have some fields where each one exists "per product" as needed (or not). At the top of the routine, I would like to do a simplistic:

try{ accObj.put('PB_Stage_UTP_OnDemand__c','testtttttt'); } catch( Exception exx ){ }

Is this "acceptable"? It tests fine. Do I HAVE to do anything with the Exception result?

Improve this question
7
  • 1
    I'd log the exception in a system.debug log. Also ideally I'd catch a sub class of exception eg dmlexception rather than top level exception lest an undesirable scenario causes the exception eg accObj being Null would cause a NullPointerException which you may or may not want to ignore
    – techtrekker
    Commented Apr 11, 2013 at 20:23
  • "Per product" suggests some loop. Pity sObjects can't implement an interface hasFieldXYZ ;) Describe() call on each sounds like an overkill... But from "philosophical" point of view are you 100% sure it's ok to "just try" without checking if field exists and isUpdateable() by current user? I'd prefer some runtime checks along lines instanceOf etc to be honest.
    – eyescream
    Commented Apr 11, 2013 at 20:26
  • (related to other posts about my Piggyback trigger) The routine goes though "all Opps for 1 account that have Product_List__c = [val]" and summarizes them onto the Account. The trigger itself is great because it started with temp vars all NULL and populates them from scratch every time (so it's Self cleaning). I'm trying to create a mechanism that starts with all null ON THE ACCOUNT where it writes as well. SOME Product_List__c entries have fields a,b,c,d,e... some have a,c,e... some have a,e... I just want to blanket null "[product]_a__c" (a,b,c,d,e) for the product being checked.
    – AMM
    Commented Apr 11, 2013 at 20:34
  • 1
    You could create a custom setting to map product fields to account fields based on product type.
    – techtrekker
    Commented Apr 11, 2013 at 20:36
  • 1
    Why can't you nullify all fields on Acc to start with? Any special reason you need the "temp variables in the trigger"? Make 1 round through trigger.old / trigger.new, collect Ids of Accounts, fetch them & nullify, make second "calculating" loop... google.com/search?q=%22on+error+resume+next%22+is+evil
    – eyescream
    Commented Apr 11, 2013 at 20:38

1 Answer 1

Reset to default
1

Based on my needs and only low-level developer knowledge to date (plus timelines involved), I'm using a solution provided here:

Set<String> objectFields = Schema.SObjectType.My_Object__c.fields.getMap().keySet();
if(objectFields.contains(fieldName)) {
  //do stuff
}
Improve this answer
1
  • 1
    This question has already been marked correct, but for anyone who come along after this: Never use a try-catch block to control logic flow. Always use some type of if-else construct. Exception handling is for dealing with problems, or things that you don't expect.
    – Wes Nolte
    Commented Apr 18, 2013 at 15:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .