Over several years, based largely on seeing code written by other developers and classes/discussion at TechQuest, I've built up a pretty standard set of exception handling practices for almost all Unity Scripts (mainly standard Workflow scripts). It includes:
1) Do all actual work in a try-catch block
2) Set the Diagnostics level based on a Configuration Item value, and log the Script's beginning and end to the Diagnostics Console.
3) On an Exception, write detailed information to the Diagnostics Console and set detail (at least the script name and a line number, maybe an abbreviated stack trace too) to a Property that can be used from Workflow.
But that led to A LOT of boiler plate that clutters up a casual reading of the script. usually the main script entry point would have ~25 lines of code, with an actual method call in the middle of it, to a method that implemented all business logic.
What I've recently switched to doing is using a Library with all that exception handling in a method that accepts a business logic method as an arguement.
Here's the signature of that method:
public delegate void WorkflowScriptDelegate(Hyland.Unity.Application app, Hyland.Unity.WorkflowEventArgs args);
public static void WorkflowScriptExecuteWithExceptionHandling(Hyland.Unity.Application app, Hyland.Unity.WorkflowEventArgs args, string scriptName, WorkflowScriptDelegate myDelegate)
Now any given individual Unity Script references that Library and looks something like this:
public void OnWorkflowScriptExecute(Hyland.Unity.Application app, Hyland.Unity.WorkflowEventArgs args)
{
LIBExceptionsGeneral.WorkflowScriptExecuteWithExceptionHandling(app, args, SCRIPT_NAME, main);
}
private main(Hyland.Unity.Application app, Hyland.Unity.WorkflowEventArgs args)
{
//All business logic here
//...
}
That makes for a script that is much easier to grok at a glance, whether you're me or another programmer or an OnBase developer who can read a little C# but really, really doesn't want to look at all the previous boilerplate at a glance.
Or sometimes all the business logic moves into a Library, and so the actual entry point script becomes extremely simple:
public void OnWorkflowScriptExecute(Hyland.Unity.Application app, Hyland.Unity.WorkflowEventArgs args)
{
LIBExceptionsGeneral.WorkflowScriptExecuteWithExceptionHandling(app, args, SCRIPT_NAME, LIBBusinessLogic.DoThisThing);
}
At that point I might have several Scripts that are called for different parts of related operations (CreateBatch, Add to Batch, Update Batch, Remove From Batch)- but each is just an entry point into a library that contains all the related business logic in one place, and doesn't need to do any of that boiler plate Exception handling (though of course it may want to do more specific Exception handling, and is still generally responsible for lots of checks to avoid Exceptions to start with).
One thing I haven't done yet is used the techniques discussed in this Community Post to information at runtime about the executing Script:
https://www.onbase.com/community/technical_communities/onbase_apis/f/unity-apis/26744/can-we-access-...
I'm still maintaining the script's name by hand and passing it into my "ExecuteWithExceptionHandling" function, but using options mentioned there to programmatically identify the calling script's name and version will be a nice improvement.
Does anyone else user similar techniques? Or have other related ideas to share that help avoid boilerplate code and manual repetitive coding of things you do a lot in Unity Scripts?
