Using try/catch blocks to try child procs

ID:2472758
 
Jun 1 2019, 1:07 pm (Edited on Jun 1 2019, 2:56 pm)
(See the best response by Ter13.)
This is a child thread of this post in Design Philosophy:
http://www.byond.com/forum/post/2472559

To summarize my old thoughts and the new idea I've come to ask opinions on, I essentially want to find a standard that best balances efficiency and code readability when it comes to players disconnecting from the game while doing something (such as conversing with NPCs, doing battle, etc). A lot of the events in question will frequently stop and wait for user input -- naturally, if the user has logged out when they are presented with input, that needs to be handled. The existing tedious method I've been using is to simply spam null reference checks with the basic

if(!usr)
    return


This is creating its own issue of practically doubling or tripling the lengths of certain procs, as they end up looking something like

FetchUserInput(arg, arg)
if(!usr)
    return
FetchUserInput(arg, arg)
if(!usr)
    return
FetchUserInput(arg, arg)
if(!usr)
    return
...


Before I continue to pump out objs and turfs that are cluttered with these null reference checks, I'd like to find a better way to handle this. Now, this is where I've had a new idea I like the best.

Most of the objs and turfs belong to overarching structured groups. Rather than doing try/catch blocks for every single obj/turf, would it be possible to implement something following this generic pseudocode?

obj/Dungeon/proc
    GeneralInspect()
        try
            Inspect()
        catch
            // handle it, because they're all similar


This way, instead of having every obj that is a derivative of the Dungeon class include its own try/catch blocks in every single Inspect(), would it be possible to rather somehow call the parent's (parent's parent's parent's ...) GeneralInspect() so that I can have just the one overarching try/catch? Or is this particular configuration impossible -- if that is the case, is there an alternative to what I am attempting to perform? Thanks in advance.
Jun 1 2019, 2:36 pm
Best response
it's possible. When you are in a try/catch, any runtime error that is generated will wind up being caught and you'll wind up in the catch block.
Jun 1 2019, 3:05 pm
Yes! Finally, this works great. Thanks for the confirmation Mr. Cage, though I think what I needed most was to just write out my thoughts. For future reference, this is what I did:

obj/Labyrinthian
    verb/GenInspect()
        try
            Inspect()
        catch
            // handle
    verb/Inspect()
        ..()

    Statue1
        icon = 'statue.dmi'
        icon_state = "gargoyle top"
        Click()
            if(src in view(2))
                GenInspect()
        Inspect()
            // stuff


And this works as intended, just the same as if I'd used Inspect() under Click() instead. This means I can have it all centralized and significantly reduce clutter. Huzzah inheritance!