Enhancement: Forcing exception during new MetadataTriggerHandler().run()

[DmitriyBereza]

Hello Mitch,

First of all thank you for the great job on the framework, it's great.

I'm working on migrating to the framework for a while and almost succeeded with the migration, the only last thing left.

We are trying to add some logic in the trigger, tracking the errors in our logger, something like this:

try{
new MetadataTriggerHandler().run();
}catch(Exception e){
SObjectTriggerUtils.logAndThrowError(e);
} finally{
TA_TriggerActionContext.clearContext('Account');
}

And unit testing of catch clause is the headache. I wonder, will you product benefit from an enhancement in TriggerBase allowing force-fail an execution? We can do that in our version since it is unlocked, by probably you will consider the change.

For example:
public inherited sharing virtual class TriggerBase {
private static Boolean forceFailExecution = false;
.
.
.
public void run() {
if (Test.isRunningTest && forceFailExecution){
//throw some exception
}
}
.
.
.
public static void forceFailExecution(Boolean forceFailExecution) {
this.forcefailExecution = forceFailexecution;
}
}

So in tests it could be used like TriggerBase.forceFailExectuion(true)

Sure, code only for illustration purposes, to pass the idea for consideration.

Thank you in advance for the answer,
Best regards,
Dima

[mitchspano]

Hello @DmitriyBereza,

That is not necessary for any of the core functionality of the framework, so it's unlikely to be included in a new version of the package.

I would also question why you are performing a top level catch like you demonstrated.
Catch blocks should be very focused in scope - they should really catch a specific exception type on a specific line.
What you're proposing above is analogous to:

public static void main(String[] args) {
  try {
    new Program.run();
  } catch (Exception e) {
    logger.atSevere().withCause(e).log("Something went wrong...");
  }
}

This code is handling every possible error in the whole program in one top level statement - I would recommend against doing something like that.

[DmitriyBereza]

Well, I guess our approaches are different then, thank you for your answer!