Exception thrown during debugging as a means of conditional breakpoint in ContentManager

[najak3d]

**EDIT: FALSE ALARM.

I'm indoctrinated into the belief that "exceptions are bad", and didn't pay attention to the localized code which clearly indicates that this was a "Debugger only" exception intended for Developer notification. So this exception is NON-CRITICAL.

The only thing I'd request is that we NOT throw exceptions (even with Debugger ATtached) for non-bad things like this. As the Animation itself is loading -- but the "_source_clip" suffixed version seems non-essential (everything seems to work without it).**

= IGNORE THE REST BELOW HERE ===

I'm working from GitHub, latest source code, Final push from "Sebastian Gregor", March 31st, 11:18.

I compiled with VS2022 - and ran Game Studio, which starts up fine.

I created an empty project first -- and it went well until I tap on an Animation like "Run" and it gives error:

"The asset 'Animations/Run_source_clip" could not be found.    (same for ALL animations)

(the Mannequin model itself loads up fine though).

So then created another project for the "Top-Down RPG" for Windows. And when it started up, gave this error:

The asset "Audio/FishLampByUlrick-EvensSalies" could not be found.    (similar as above)

=====

So it seems like the latest GitHub code has a critical issue with packaging/using the Assets that are supposed to be automated when you make these Game projects from Game Studio.

Note also that for the RPG Demo... despite 2 audio files being missing, it does compile and run -- and seems fine.

But from within GameStudio ,the RPG game also has the same issues as the empty Game -- if you tap on ANY Animation, it waits about 5 seconds, then throws an exception that "The asset "Animations/{animName}_source_clip" could not be found"

That exception throws 5 seconds after tapping on the animation in Game Studio:

[najak3d]

More on this one. So for the RPG game, the mannequin is already rigged with Animation Controller and 4 animations -- these all work.

However in Game Studio, although I can see them -- if I click on any of these from inside the Animation controller -- I get the same thrown exception shown above that "Asset... could not be found".

NOTE: I CAN still drag/drop animations in Game Studio.

The above exceptions are triggered by the code that is attempting to "Preview":

[najak3d]

More on this -- perhaps this bug is "non-critical" -- if so, then the code should be changed to remove the exception.

For some reason, each Animation is deserialized TWICE -- the first time is "Animations/Run" (no suffix), then a couple seconds later, deserialization is attempted again, but this time with "_source_clip" suffix - and it throws. If this is OK, then the exception should be removed, and not-even-attempted if the file is missing.

Here's the code from AnimationPreview that triggers the reload with "_source_clip" suffix:

(SrcClipSuffix here is "_source_clip")

[najak3d]

OK - learning more here -- I see that the exception only happens for "Debug mode" -- which still seems excessive, as Devs should always be doing "Break on Exception" -- so this is guaranteed to throw Alarms (as it did here). Non-essential assets (which I assume the "_source_clip" is non-essential) - should not throw exceptions.

Even in production/release -- for this case, an "Error" also might be "too-strong", as this condition is apparently "OK" (not an error).

[najak3d]

Another suggestion here is to do the following, where we are trying to throw errors as exceptions inside DEBUGGER only.

Just do the Log.Error, and let the developer have a global setting as to whether or not Log.Error will throw exception in Debug Mode -- or something like this.

The current repeats in logic to decide whether to Throw or just Log an Error -- should in some way be centralized, and managed from one location. That way the behavior can be controlled from ONE spot in the code, so you can turn on/off Exception for debug mode in one place, rather than "spread throughout the code".

[manio143]

I understand where you're coming from, but making the code exceptions free would be a very hard thing to achieve - there's a lot of places, especially web/ui, where exceptions being thrown and acted on is the norm. You need to be mindful about the context of each exception and in this case the comment above the if clearly explains why this approach was taken - conditional breaking. In this particular case if someone needs to break here they can just put a simple breakpoint (not even conditional), but I'm assuming it was important for whoever wrote this that people are aware about this being a spot critical enough to warrant such a construction.

I'm gonna let others express their opinion here. Changing title of the issue to reflect what it's about.