Change runtime error to the nullptr returning

[TatyanaPolunina]

• We are attempting to create shaders during the update of layers. It seems more appropriate to return a nullptr for a shader that fails to create, rather than stopping the app if one shader is not created (as exceptions are not caught).
• Proper handling is implemented in all callers when a shader is nullptr, so we should not experience inconsistent behavior in such cases.
• Most shader creation errors are related to low memory on iOS. Since we have lazy initialization for shaders, the behavior may be restored in the next level update if iOS frees the necessary memory.

[adrian-cojocaru]

Returning null works, but on each subsequent call of getOrCreateShader the same shader creation will be retried and it can end up compiling the same code multiple times per frame.
An empty/debug "Null" shader should fix this, but I don't think the current checks can handle it.
Either way a performance hit is better than an unhandled exception.

[TatyanaPolunina]

Returning null works, but on each subsequent call of getOrCreateShader the same shader creation will be retried and it can end up compiling the same code multiple times per frame. An empty/debug "Null" shader should fix this, but I don't think the current checks can handle it. Either way a performance hit is better than an unhandled exception.

Potentially it could be even better. As shader is not created, that's why we have Null. Also we usually have "compile error" together with "memory warning" on IOS, so I expect that on next "updateLayers" IOS could clear the memory and we would correctly create shaders so app would work. But need to be investigated for sure

[github-actions]

Bloaty Results (iOS) 🐋

Compared to main

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  [ = ]       0  [ = ]       0    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results-ios/pr-3184-compared-to-main.txt

[github-actions]

Bloaty Results 🐋

Compared to main

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  [ = ]       0  [ = ]       0    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results/pr-3184-compared-to-main.txt

Compared to d387090 (legacy)

    FILE SIZE        VM SIZE    
 --------------  -------------- 
   +31% +36.1Mi  +438% +26.2Mi    TOTAL

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/bloaty-results/pr-3184-compared-to-legacy.txt

[github-actions]

Benchmark Results ⚡

Benchmark                                                     Time             CPU      Time Old      Time New       CPU Old       CPU New
------------------------------------------------------------------------------------------------------------------------------------------
OVERALL_GEOMEAN                                            -0.0044         -0.0043             0             0             0             0

Full report: https://maplibre-native.s3.eu-central-1.amazonaws.com/benchmark-results/pr-3184-compared-to-main.txt