Your Digital Media Has Never Looked So Good

 
JohnBasedow
Topic Author
Posts: 46
Joined: Sun Sep 22, 2013 8:38 pm

API Request: Allow registering exception-handling function

Tue Jun 17, 2014 11:21 am

I think it would be extremely helpful if a channel were able to register a single exception-handling function so that when an exception occurs, a message could be displayed to the users, and possibly reporting of the crash to an external source like GetSentry.com.

At least the channel could fail semi-gracefully, versus the hard stop or lockup that occurs when an exception occurs in the channel.
 
User avatar
RokuMarkn
Roku Engineering
Posts: 1581
Joined: Mon Jun 09, 2008 9:20 am

Re: API Request: Allow registering exception-handling functi

Tue Jun 17, 2014 12:03 pm

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
 
JohnBasedow
Topic Author
Posts: 46
Joined: Sun Sep 22, 2013 8:38 pm

Re: API Request: Allow registering exception-handling functi

Tue Jun 17, 2014 12:43 pm

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)
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

Re: API Request: Allow registering exception-handling functi

Tue Jun 17, 2014 1:37 pm

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
Posts: 708
Joined: Wed Feb 10, 2010 4:21 pm

Re: API Request: Allow registering exception-handling functi

Tue Jun 17, 2014 3:03 pm

No one has really explained how the Roku loads channels and executes them.
BUT 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.

It would be nice if we could register a contingency routine, either in the package manifest or via 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.
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

Re: API Request: Allow registering exception-handling functi

Tue Jun 17, 2014 4:09 pm

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?
 
JohnBasedow
Topic Author
Posts: 46
Joined: Sun Sep 22, 2013 8:38 pm

Re: API Request: Allow registering exception-handling functi

Wed Jun 18, 2014 9:09 am

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.
 
User avatar
RokuMarkn
Roku Engineering
Posts: 1581
Joined: Mon Jun 09, 2008 9:20 am

Re: API Request: Allow registering exception-handling functi

Thu Jun 19, 2014 2:00 pm

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

--Mark
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

Re: API Request: Allow registering exception-handling functi

Thu Jun 19, 2014 3:02 pm

Much obliged!
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

Re: API Request: Allow registering exception-handling functi

Sun Sep 18, 2016 3:09 pm

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...
 
User avatar
RokuKC
Posts: 315
Joined: Wed Sep 10, 2014 10:44 am
Location: Roku HQ

Re: API Request: Allow registering exception-handling functi

Mon Sep 19, 2016 12:05 pm

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.
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

Re: API Request: Allow registering exception-handling functi

Mon Sep 19, 2016 12:49 pm

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).

Who is online

Users browsing this forum: No registered users and 2 guests