[Request] Try-block style construct

[VariableVixen]

This would mainly be useful for adding tooltips to items without needing a separate file for each mod, in case one is removed. Something like

try {
    <mymod:unexplainedItem>.addTooltip("Here's how to use this item");
}
try {
    <anothermod:strangeItem>.addTooltip("More information on this item");
}

where each try block is separate, and an error in a try block would abort the block (like an error in a file does now) but continue execution outside the block. Obviously, this could be complicated with regards to variables, but I'm hoping it could be worked out. Maybe you couldn't declare a var or val inside a try block? It's basically a dogwash, cause I can just make a bunch of files, but it'd be a nice thing to have if it's possible.

[Blue64]

I believe you already can't do a var/val inside a block if I'm not mistaken. (I read about it around a month ago, and I don't recall the age of the post, I think it was a FTB forum somewhere, or CurseForge), the val would definitely be a bad idea in a block because it can't be changed later if it gets called again lol but I see your point.

Doesn't it only soft-fail if it's a var/val call though? Example:

val unexplainedItem = <mymod:unexplainedItem>;
val strangeItem = <anothermod:strangeItem>;

unexplainedItem.addTooltip("Here's how to use this item");
strangeItem.addTooltip("More information on this item");

And by "Soft Fail" I mean it fails the command, but continues the script.

[VariableVixen]

As far as I know, it hard-fails if it can't find the item, regardless of where it's used. I can check again though, I might be wrong.

[Blue64]

I'd check again, because I'm fairly certain I was using scripts that attempted to use invalid items (updated Better Sugar Cane for example, and they changed <bettersugarcane:bsCaneGoldSword> into <bettersugarcane:BSCaneGoldSword> thus throwing an error (Case Sensitive lol)), and it still ran the script, just spammed error messages also.

Edit: Merged Post: It'd be a good idea for a command to attempt it without spamming errors if it _soft-_fails though! Is there a way already to do that? (Perhaps it could spam the errors to the client-latest.log without spamming Chat at least if used via /mt reload)