[bug] [player] Crash on single level with tileset missing

[Simon]

Hi,



Related chat on 2016-07-06 at 21:00 UTC:

Gronkling: SimonNa: Thanks for the backroute! here's a V2 of the level which will be included in the finished game (unless any other backroutes are found) https://drive.google.com/open?id=0B24bnHjK2QUDTGNhMWNxeWJVNlU
SimonNa: Gronkling: that level segfaults NL immediately on loading the level. What NL version do you use?
Gronkling: im using v1.43 for the player
SimonNa: okay, hmm
SimonNa: maybe I lack the tilesets, and the game doesn't give a proper error
Gronkling: just checked and i can load in my player
SimonNa: okay, cool
Gronkling: yes that might be it because i bundled the tilesets with the nxp

-- Simon

[namida]

Current behaviour is (in regards to stable version, when running a level either from an NXP or a LVL file (ie: NOT when running one via testplay mode from the editor)):
1. Check "styles" folder for appropriate graphic set
2. If running from an NXP, check in the NXP for the appropriate graphic set
3. Check internally-stored data for appropriate graphic set
4. If online functionality is enabled, check NeoLemmix website for appropriate graphic set
5. If all else fails, crash

We can hypothetically discuss what it should do in various cases, but at the end of the day, since almost every relevant part is being overhauled in some way, it'd be somewhat pointless. However, in the most generic form of this - "fail silently if possible and reasonable, and if not, at least attempt to fail gracefully" - it's something that needs to be considered.

[Simon]

The lookup sequence is okay, but print an error at least if everything fails. What's wrong, and what shall I try to resolve the error.

-- Simon

[Crane]

It's always good programming practice to give a meaningful error message instead of letting an exception raise, and in this case, saying "Style data missing" or some such note is better than "Segmentation Fault" or "Access Violation" being thrown at a user who may not be savvy in the intracacies of interrupt signals.

I've heard of situations where end users would try to type out the word "mismatch" on the keyboard when a poorly-programmed menu in a Visual Basic application caused the unhandled error "Type mismatch" to appear.  Of course, typing out said word does nothing to help!