I have written a scheduler class which can schedule a batch job to run every 15 min. I wish to handle a scenario – if there is any exception during scheduling I do not want the chaining of scheduled job to be aborted. The job should keep on getting scheduled even there any error somewhere in the code.
public class abcSchClass implements Schedulable{
Integer timeInterval;
public abcSchClass(Integer timeInterval){
this.timeInterval = timeInterval;
}
public void execute(SchedulableContext sc) {
try{
// Re-schedule
System.debug('Enter Scheduler class');
DateTime now = DateTime.now();
DateTime nextRunTime = now.addMinutes(timeInterval);
String cronString = '' + nextRunTime.second() + ' ' + nextRunTime.minute() + ' ' +
nextRunTime.hour() + ' ' + nextRunTime.day() + ' ' +
nextRunTime.month() + ' ? ' + nextRunTime.year();
System.schedule(abcSchClass.class.getName() + '-' + now.format(), cronString, new abcSchClass(timeInterval));
// Abort the current job
Id jobId = sc.getTriggerId();
System.abortJob(jobId);
// Launch the replacement order batch job
abcbatch b = new abcbatch();
database.executebatch(b);
system.debug('done scheduling');
}
catch(MyExceptionClass e){
}
}
}
I just need to run this code from Execute anonymous and it starts scheduling itself every 15 min. How can I handle the exception here? If there is any error in scheduling the current job then the subsequent scheduling should not be aborted permanently. Also I have built my own custom exception to manager exception. Below is my exception class
public class MyExceptionClass extends Exception {
public MyExceptionClass( Exception e, string sourceClass){
throw(e);
}
}
How can I use this exception class to manage my exception/error scenarios?
Best Answer
This is realistically impossible. The reason why, of course, is Governor Limits. The way your code is written, if a governor limit hits you, you're dead in the water, indefinitely, until someone creates a new job to start over.
Your best bet would be to simply schedule four jobs that run hourly, 15 minutes apart from each other. While that does seem kind of greedy, it does offer some modicum of reliability, because you're guaranteed to pick up correctly on the next 15 minute window.
That said, if you want maximum reliability, this is one of those times where you probably want to catch Exception (but, make sure you report the errors somewhere!).
The approximate pseudocode for resilient scheduling would look like the following.
Instead of creating a cron job string that only works for the next run, instead schedule it to run with wildcards, like this:
This means that, even with a governor limit halt, your code will be delayed for an hour instead of dying off never to come back again.
As a further concept, perhaps you could simply create a job that runs hourly, and leverages scheduleBatch instead:
Which will allow you to at least kick off the jobs, and the scheduler will simply remain scheduled hourly using the cron string "0 0 * * * ?".