Fast but No Exceptions - Why recommended?

So, as described in the doc:

1. Fast but no exceptions provides no perf benefit on IL2CPP
2. Yet the : "we recommend using Fast but no exceptions on release builds
to avoid undefined behaviour."

Why this is the case?
By avoiding undefined behavior, is this referring to crash the game immediately when native exceptions happens so that game don't continue to run in an undefined state?

It's quite confusing without much context provided. Can someone clarify this?

Thanks a lot!

 

This is how I understand it.

 

If a script gets an exception with "slow but safe", it will stop executing at that point, which means your code will not do what it's intended to do, leading to "undefined behaviour".

 

I stand corrected.

(although, for clarity I didn't mean the app will not continue to run, I just meant the rest of the specific script that got an exception will not run, which has been my experience, although it may have been cause a lot of the rest of the code depended on that null not being null?)

 

Sorry for being the gravedigger here, but I'm trying to understand a little bit more about what you mean by: "avoiding undefined behavior".

Can you clarify a little bit better of what is this behaviour and why avoiding it its important?

And this is nowadays valid to Android as well?

 

That's perfect! I actually caught the exact issue that you mentioned in a released build with SlowAndSafe! And caused a lot of other problems! Thanks for the explanation!

About the android builds, so basically android works by default as FastButNoException? Would be correct to assume that?

 

Thank you so much for the feedback!

 

I recall we had some issues with exceptions not crashing in Android. For testing purposes we had to force the app to crash when a unhandled exception was thrown, but from your answer this should not be true.

Also by a managed exception you mean exceptions thrown in C# user code correct?

 

I can't find anywhere in the docs what callback will be invoked before the crash, using the FastButNoException setting. I need to track the error before the app crashes, previously AppDomain.CurrentDomain.UnhandledException was invoked but I'm not sure that's the case anymore.

@JoshPeterson what event should I subscribe to, in case I want to know about the exception, just before the crash using fastButNoExceptions?

 

Just a note, I always used Fast but no exceptions for my games. mostly because of the better performance idea.

I had an InvalidCastException in a test version of my game today that would crash it. Something I was going to remove, but instead I thought it was a good chance to test how Slow and Safe would handle it.

My game wash crashing on an InvalidCastException but it kept playing when I was on Slow and Safe. It didn't appear to affect the gameplay, but I think I am going to release my next update as slow and safe because why not if you reduce crashes and there's no performance hit.

I will leave it on Fast no exceptions while I am testing though, because its good to catch every problem you can - a bug free game is better. But I don't see any reason not to publish with slow and safe since its just an extra layer of protection against player frustration, presuming any invalid states allowed to continue don't adversely affect gameplay, or represents a good enough trade off.

 

The biggest problem with Slow and Safe is: You game can end in what unity calls "Undefined Behaviour" and this can cause way more harm than a simple crash, for instance in a project I've worked in the past we had some cases of using corrupting their whole save data because of a random crash that was supposed to crash the game but It didn't since was published on Slow And Safe.

For me it should be the other way around, use slow and safe on development since this can spill out more information to help you fix those crashes, but releases, always with Fast but no Exceptions.

 

Hi @JoshPeterson I tested the option "Slow and Safe" vs "Fast but no exception" on iOS 16, Unity 2021.3.2f1

I intentionally make a nullref exception when a button is clicked.

I built within unity as release build, generated the Xcode project, and I ran both of my project in Xcode debug build.

Expectation
- Slow and Safe: App does not crash
- Fast but no exception: App crashes

Actual result
- Slow and safe: App didn't crash
- Fash but no excception: App didn't crash

Is this a correct behaviour? Does "Fast but no exception" option's "crashing immediately" happens only if both Unity and Xcode is built with Release option?

 

I didn't find any meaningful logs from player logs.

I tested using various scenarios and here is the results:

1. Editor

1. The exception had occured on the Main Thread

- Slow and safe: Exception detected, and the game keeps running
- Fast but no exception: Exception detected, and the game keeps running​

2. The exception had occured on a Task that was running on a Background Thread

- If the task was awaited, then both mode catches exception
- Else, then both didn't catch exception​

2. iOS Device

1. The exception had occured on the Main Thread

- Slow and safe: Exception detected, and the game keeps running
- Fast but no exception: Exception detected, and the game keeps running​

2. The exception had occured on a Task that was running on a Background Thread

- Slow and safe: No crashes wether the task was awaited or not
- Fast but no exception: Crash occurs only if the exception is thrown from a task that is awaited on main thread​