The ASSERT and CRASH procs stop the current procedure but the parent continues. This doesn't seem like reasonable behavior, especially because the same effect can be achieved with the return statement.
Numbered Steps to Reproduce Problem:
Code Snippet (if applicable) to Reproduce Problem:
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
Expected Results:
runtime error: x must be positive.
proc name: square root (/proc/square_root)
usr: Forum_account (/mob)
src: null
call stack:
square root(-3)
Forum_account (/mob): Test()
Actual Results:
runtime error: x must be positive.
proc name: square root (/proc/square_root)
usr: Forum_account (/mob)
src: null
call stack:
square root(-3)
Forum_account (/mob): Test()
1
Note that the "1" is printed after the call to square_root, verifying that the parent proc/verb continues after a call crashes. The same thing (except for a slightly different error message) is seen if you use ASSERT(x >= 0) instead of CRASH.
Does the problem occur:
Every time? Or how often?
In other games?
In other user accounts?
On other computers?
It appears to happen every time.
When does the problem NOT occur?
When an actual error occurs, not one generated by ASSERT or CRASH.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Not sure.
Workarounds:
proc/square_root(x)
if(x < 0)
. = new /mob()
CRASH("x must be positive.")
return sqrt(x)
mob/verb/Test()
var/a = square_root(-3)
world << a + 1
Because we know the parent proc is expecting a number we can return a mob with the hope that it uses this value in arithmetic and gets a "type mismatch" error that actually crashes the proc.
I think this still belongs in the feature tracker where it was originally posted. The current behavior may not be what you want but it is not a bug.