Roku Developer Program

[JohnBasedow]

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.

[RokuMarkn]

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]

"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]

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]

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]

"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]

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

[RokuMarkn]

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

--Mark

[EnTerr]

Much obliged!

[EnTerr]

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