Timeline for Bests practices for handling potential errors as a result of time based workflow
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 14, 2014 at 23:32 | history | bounty ended | CommunityBot | ||
| Jan 9, 2014 at 1:12 | comment | added | Tim Smith | Since @Ralph mentioned .addError, I was thinking that the error was being caught within the trigger -- in which case the record could be created within the catch en lieu of the .addError. | |
| Jan 8, 2014 at 23:41 | comment | added | eyescream |
Interesting but messy. The transaction will fail (that's the whole point, right?), there will be rollback. So how would you save such "side effect"? I think @futures are not queued in such case, ditto with queued outbound emails... I'm not downvoting you, just thinking out loud. But I "don't see it". Savepoints within a trigger? Yuck (if possible at all). In such case I guess I'd ditch time-based w. and go with scheduled batch, would be "cleaner".
|
|
| Jan 8, 2014 at 20:33 | history | answered | Tim Smith | CC BY-SA 3.0 |