ASSERT/CRASH

ID:100911
 
Aug 25 2010, 8:11 am
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
This is part feature request, part bug report. It seems like the behavior matches the intended behavior, but the intended behavior doesn't make sense.

When ASSERT fails or when CRASH is called the current proc is stopped but the parent proc continues. If you have something like this:

proc/square_root(x)
    if(x < 0)
        CRASH("x must be positive.")
    return sqrt(x)

mob/verb/Test()
    var/a = square_root(-3)
    world << a + 1


CRASH prints the error message and stack trace but the Test verb keeps running and prints "1". The square_root proc crashing affects the rest of the verb so I'd want the whole thing to stop. If I only wanted the square_root proc to stop I'd use a return statement instead of the CRASH proc.

The only benefit CRASH gives you is printing the stack trace. This seems to limit its usefulness.
Aug 26 2010, 6:33 am
Everything should just be implemented into the pager. Steam, for the 1000th time.
Aug 26 2010, 6:38 am
Falacy wrote:
Everything should just be implemented into the pager. Steam, for the 1000th time.

I have no idea how that relates to this, but thanks for bumping my feature request =)
Aug 26 2010, 6:39 am
Whoops, posted that on the wrong thing.
Jan 3 2016, 3:31 am
This is (unfortunately) the intended behavior.

It would be nice to see this not occurring if you're throwing exceptions around, but I'm not sure if this is feasible to implement at this time.

How exceptions normally work is that they go up the chain, preventing code from executing until the exception has been caught. Unfortunately this is not the current behavior.

Would this behavior be easy to introduce? Perhaps with a compile-time flag that has to be set as not to interfere with older projects? (Ideally this flag is turned on for new projects.)

If not, then I think this is redundant.
Jan 3 2016, 3:59 am
If there is a try-catch block anywhere up the stack, exceptions will propagate upwards to there. If there's not, they'll only crash the current proc, just like runtime errors.
Jan 3 2016, 4:02 am
The ideal situation (for me anyway, but I bet more would agree) is that if the exception is not caught anywhere that it logs the runtime error and completely aborts the current proc chain (i.e., goes all the way to the top and then stops + logs).

The last thing you want is for code to continue running when you have an uncaught error condition.
Jan 3 2016, 4:20 am
In response to NullQuery
NullQuery wrote:
The last thing you want is for code to continue running when you have an uncaught error condition.

Are you trying to stop development for most anime-related games? /sarcasm
Jan 3 2016, 9:42 am
Heres an idea:

- world.loop_checks
+ world.code_safety_flags

BACKGROUND_LONG_LOOPS
RUNTIME_ON_STACK_OVERFLOW <---spliting this up with background long loops so we can disable loop checks without losing protection from crashing dd on stack overflows would be nice
RUNTIME_ON_TYPE_MISMATCH <---- PLEASE! (This would cause a runtime if you attempt to assign a value to a typed var that doesn't match that vars type) It would allow us to remove millions of istype() checks and force proper typed programming (it might have to have a short circuit for clients to datum mismatches until clients become childs of datums)
EXCEPTIONS_STOP_THE_STACK
ALL_RUNTIMES_STOP_THE_STACK

I highly doubt this will make it into 510, but i'll bump this thread for 511.
Jan 3 2016, 11:13 am
Runtime on type mismatch is impossible. The check for it even when off would be a performance drag. The only way I can think of making this work would be a special assignment operator, but even then that might require changes to the other assignments like += as well.
Jan 3 2016, 11:18 am
eh, its a pipe dream, i know.

You could store the type on references in a way where you only need to do a starts_with comparison of the type string, but that has other issues and would still cause performance issues. (assuming you don't already do this)