I have developed a workaround for this problem that might have wider applications. If a bug in a method call of a system function (or similar) breaks the assembly of an entire page, then executing it while passing it as a parameter to a macro seems to allow you to test for failure and deal with it gracefully. I have no idea why (perhaps someone could suggest an explanation) but the following macro…
#macro(ExecuteIfValid $whatever $returnvalue)##
#if($whatever)##
#set($returnvalue = $whatever)##
#else##
#set($returnvalue = "")##
#end##
#end##
…allows me to do this…
#ExecuteIfValid($rx.keyword.getChoiceLabel('cmsEvent','event_type',$sys.item.getProperty("rx:event_type").String) $selectedlabel)
$selectedlabel
…and have it display the selected label only if the getChoiceLabel() method returns a valid result of some kind, whereas this seemingly equivalent code…
#set($selectedlabel = $rx.keyword.getChoiceLabel('cmsEvent','event_type',$sys.item.getProperty("rx:event_type").String))
#if($selectedlabel)
$selectedlabel
#end
…breaks the entire page when previewing while logged in to a community that does not have runtime access to the cmsEvent content type, displaying the following error message…
Problem assembling output for item: 1-101-822 with template: cmsPgExtEvent exception: item definition must not be null see log for stack trace
This particular bug has been raised with technical support, and has an RX number, but I thought I’d post the above because it could be useful in similiar situations. No substitute for proper exception handling with try-catch blocks, but it might help someone else out of a sticky situation.