ID:1868951
 
(See the best response by Ter13.)
In BYOND 508, Lummox added try and catch.
Could anyone tell me how these are used with an example? I cant seem to understand whats their use so far.

Thanks in advance. :)
Best response
I'm unsure of the current implementation, this might be a little off, fair warning, but the concept should be pretty much the same as Java:

Basically, any time that BYOND has a runtime error, a function can now "throw" an exception.

proc
something(num)
if(num>0)
//carry on
else
throw new/exception("invalid argument",__FILE__,__LINE__) //Note I don't know the actual constructor structure. This is a guess.


When you throw an exception manually, it's just like a runtime error, only with a custom message.

Now, you can try to perform an action that might generate an exception, and if that exception is generated, you can catch the exception and prevent the runtime error from showing up and stopping code execution like normal. You do this with try/catch.

try
something()
catch(exception/e)
if(e.name=="invalid argument")
world.log << "Invalid argument passed. Runtime prevented."
else
throw e //unhandled exception


The catch block is sort of a special-case if statement that says: "If we try something, but it fails, do this instead.".

Exceptions allow you to respond to garbage data safely without having to do a ton of safety checking before-hand. If used effectively, it can make code faster by eliminating unnecessary sanity-checking and instead simply responding to errors that occur.
If a proc crashes, before we had a catch it killed the entire chain. Now we can specify where to kill it to (using try) and then run another set of code instead.

I.e.

try
mysql_connect()
catch
sqlite_connect()
In response to Pirion
Actually not quite. Without try/catch a proc crash should only impact the proc that crashed, not the entire chain.
Actually not quite. Without try/catch a proc crash should only impact the proc that crashed, not the entire chain.

Are you saying the default behavior for an unhandled exception is to eject without a stack trace?
In response to Lummox JR
Hmm, I thought this was happening before for some reason...maybe I was mistaken.

I tested in the build before and looks like I am. The crash only occurs in the current proc. I had a return value coming back that was never set, which caused it to look that way.
In response to Ter13
Ter13 wrote:
Actually not quite. Without try/catch a proc crash should only impact the proc that crashed, not the entire chain.

Are you saying the default behavior for an unhandled exception is to eject without a stack trace?

The default behavior is to exit the proc that threw the exception, and return to the caller. If there's a try/catch involved, the stack will always unwind to the catch.
Oh good, I misunderstood the implication of what was being said here.

Out of curiosity, was my constructor right? The notes for 508 didn't publish, so I haven't upgraded yet. EDIT: Seems they posted.
In response to Ter13
Your constructor looks fine, although you can save some time with the EXCEPTION() macro.

It occurs to me I forgot to update the online reference, although I'm not sure if that's the right call for the beta.
Thanks. I'll just give the new material a peruse. Thanks for your hard work on 508.

"Lay-zer"
Am I the only one finding this feature a little bit weird? I know I use it in C# and I do think it's cool but the thought of using it in DM sort of freaks me out.

I'm so used to precise control, knowing exactly what possible errors a code would have and countering it. The thought that I'll just leave a code hangin' to be later caught, it scares me.

I'd still prefer to do sanity checks, unsure whether it's the better way or not but I'd still rather write the 2-3 extra ifs.
IMO, doing sanity checks is worthwhile regardless; it's just good programming. The best place I can think of to use this is 1) in cases where speed is critical and errors are unlikely, where it makes more sense to let DM's internals handle it, or 2) when calling a routine you know may be problematic.
From MSDN about C# - I assume this applies here too:

The method you choose depends on how often you expect the event to occur.

Use exception handling if the event doesn't occur very often, that is, if the event is truly exceptional and indicates an error (such as an unexpected end-of-file). When you use exception handling, less code is executed in normal conditions.

Use the programmatic method to check for errors if the event happens routinely and could be considered part of normal execution. When you check for errors programmatically, more code is executed if an exception occurs.


Source: https://msdn.microsoft.com/en-us/library/ seyhszts(v=vs.110).aspx