Better error handling in official modules.
Community Forums/Monkey2 Talk/Better error handling in official modules.
| ||
| Rather than just failing and highlighting the line that failed giving the coder no clue whats going on could we have better error handling on all BRL official modules. As an example mojo2 fails on my laptop (error in bug report section) for me to find out apparently it needs OpenGL 3 surely a simple check in monkey for OpenGL 3 would allow for a little error popup that says 'this needs opengl3' or something like that. Error sorting is one of the areas where BRL languages failed in the past with cryptic and sometimes unfathomable errors it would be nice if the BRL modules would have decent error checking at compile time to make sure it all fits the bill and errors that come after are our own fault. |
| ||
| Generally speaking, I think the standard libraries brl and [whatever mojo's replacement will be] should make better use of MX2's built-in functionality. Not just having more exceptions be thrown instead of erroring out, but to have apps which return from a thrown exception maybe have some reflection capabilities (at least in Debug mode) in the quit message to know what type of exception was thrown. Or maybe Throwable could force implementation of a Name and/or Description property. Right now, I tend not to use Try..Catch blocks much, because uncaught exceptions throw a very cryptic error, which is often far less useful than the actual runtime error. Having a standard description available for all Throwables could at least allow a simple default Catch which is more helpful than not having exception handling at all. Other things to consider: * Standard containers should make more usage of generic interfaces for things like sorting and collating. * Non-fatal "missing functionality" in certain BRL classes for certain targets shouldn't cause a compiler error, but issue a warning instead. Let the runtime handle it, or throw an exception for NonImplementedFunctionality or something. * There should actually be a way to have the compiler issue warnings! |
| ||
I know many people dislike checked exceptions (including Mark), but what might be useful is to have them display an optional warning if they are uncaught, rather than force the developer to catch them.Function Foo() Throws BarException ' ... End Foo() ' optional compiler warning that BarException is uncaught Try Foo() ' no warning Catch(e:BarException) ' ... End |
| ||
| I waa meaning extending compiler directives so it catches the requirements of the modules and reports if you dont have the requirements. |
   |