API Request: Allow registering exception-handling function

Well, you can do that today with Eval(). The main issue is, if your code crashes, it may not be in any condition to display a screen or do a URL transfer. At best, the exception handler has to be written very carefully to have minimal dependencies on other parts of the application.

--Mark

"RokuMarkn" wrote:
Well, you can do that today with Eval(). The main issue is, if your code crashes, it may not be in any condition to display a screen or do a URL transfer. At best, the exception handler has to be written very carefully to have minimal dependencies on other parts of the application.

--Mark

Let's say I eval() the main entry point for my channel, will everything then run in the context of that eval() statement, and not cause the channel to crash? (i.e. the exception happens 5 screens down the chain)

You can make the main() an empty shell that does Run(fileNamesArray) for the real code and then use GetLastRunCompileError() and GetLastRunRuntimeError() to check the results (see example under 6.5 Run). Looking at it from another angle, that is having a single exception-handling function, named Main().

Surely it would be nice to have a "try ... except ..." construct in BrSc. But seeing how Perl doesn't have one...

"greubel" wrote:
wouldn't the eval() of your code cause the same overhead as when you initially load the channel ?
I know I have a large package and this would be too much.

Eval() does spend time on compiling the code first of course - moreover eval() "leaks" memory on repeat invocations (allocating new space for bytecode - so don't call it 1e38 times). But if you execute most of the code with a Run() from a "lightweight" main, the channel would start faster and you can show new splash screen before invoking Run() and the lion share of loading has started. The total load time will be the same but channel can be made seem faster to start. Note, the rest of the program will have to be stored in files with extension != .BRS

I would like to see some sort of display, maybe the function module and line number with error that the user could send.
We as developers have no idea if our channels are even functioning unless someone emails us a problem.

It is unfortunate that currently GetLastRunRuntimeError() only returns a numeric code but no file/line info. That can easily be fixed if it is extended akin to GetLastRunCompileError(), so that when optional param is passed it will return key/value AA instead:

' extended signatures
function GetLastRunRuntimeError(verbose=false as Boolean) as Object
function Eval(code as String, verbose=false as Boolean) as Object

' fictitious/desired behavior - note Eval() by definition returns GetLastRunRuntimeError()
> e = eval("? 1/0", true)
> ? type(e)
roAssociativeArray
> ? e
ERRSTR: Divide by Zero.
FILESPEC: $LIVECOMPILE
ERRNO:  20
LINENO:  398

This way we'll get the file/line info (and why not stack dump - fancy future) - while it is easy to implement and consistent with language design so far.

Any consideration of this, RokuMarkN?

"EnTerr" wrote:
You can make the main() an empty shell that does Run(fileNamesArray) for the real code and then use GetLastRunCompileError() and GetLastRunRuntimeError() to check the results (see example under 6.5 Run). Looking at it from another angle, that is having a single exception-handling function, named Main().

I'll give this a try, as I tried the eval() route last night, and by injecting a runtime error, the channel still crashed hard.

If bootstrapping is a solution to exception handling, then I'm ok with that. I just think it would be more beneficial to have the ability to register an exception-handling function that could be run before the channel exits due to the error.

Thanks for your reply.

The request for more detailed error data from Run() seems reasonable. I've filed an enhancement request.

--Mark

Much obliged!

"RokuMarkn" wrote:
The request for more detailed error data from Run() seems reasonable. I've filed an enhancement request.

Any progress on this one, RokuMarkn?
It's been couple of years since, did it get kiboshed? It's fairly trivial item...

"EnTerr" wrote:
Any progress on this one, RokuMarkn?

No plans for this at this time.  Runtime errors are (intentionally) fatal, so I don't see a use case for it that we would want to encourage.

"RokuKC" wrote:

"EnTerr" wrote:
Any progress on this one, RokuMarkn?

No plans for this at this time.  Runtime errors are (intentionally) fatal, so I don't see a use case for it that we would want to encourage.

I have couple of strong use cases from the field:

1. Roku Scene Graph - the lack of support for "function" type in Nodes, passing between threads and interpreters is so glaring, i find myself in dare need to use eval(). Or do you have good news forthcoming, of function literals being added as genuine RSG field types ? 😉


2. RAF (Roku Advertisement Framework) has proven itself historically unreliable and crap-outing, hence use of eval() is required to prevent RAF barfing. The RAF developer may swear on a stack of Rokus it won't be happening again - excuse me for not believing them since from users' point of view it's my lower back that's on the line. Or is there a full-blown exception handling coming to B/S?

While one may hope for both happening in some brave new world, i need this functionality at present time (as in "NOW" - or to avoid corporate ROTFL 8-), "within 2-3 months time") - and i figure i can make-do with as little as the requested - runtime exit codes to return more detailed info on where it happened (even if LINENO were to be off-kilter). It will help me both during development in (1) and diagnosing published app in case (2).