On Fri, May 29, 2009 at 5:13 PM, Abdulaziz Ghuloum<[email protected]> wrote: > > On May 29, 2009, at 10:28 AM, Derick Eddington wrote: > >> If --warnings-fatal makes &ikarus-warning exceptions exit ikarus, that >> sounds good. But I don't think it should make &warning exceptions exit >> because those are the users' programs'/libraries' responsibility to >> handle because the R6RS semantics is for the base handler to return. > > > True that it's required that the base handler to return. But > Ikarus's base handler does something different: it prints the > condition *then* returns instead of just returning, right? > So, this might be considered a non-conforming behavior.
Maybe there should be --exceptions-to-file which redirects the base handler's printing of all exceptions. > The default behavior should (I guess) be to print the warning > then return (as it currently is). When the program runs, the > user should be able to intercept the exceptions and do > whatever the user pleases (as they currently can). The > question here is of two parts: > > 1. about handling warnings that the user *cannot intercept* > (such as ones that happen when libraries are initialized > before the script's body, containing the exception handler, > is executed). > > 2. about handling warnings that the user *did not raise* > (such as compiler warnings). > > Part 2 is not important, I would argue. Ikarus's own warnings > should not receive a more special treatment than a warning > issued by any other library that your program happens to use. > It's better to handle all warnings on equal bases. I was imagining users desiring that &ikarus-warning exceptions be fatal (e.g. because everything is expected to be setup/precompiled already) but that the base handler return for all other non-&serious exceptions (because that's the standard behavior). > Part 1 can be handled in some ways already. For example, one > can write a wrapper script that installs an exception handler > around a ``load-r6rs-script'' of the real script. So, the > user already has total control of the situation which is a > good thing. It's just a little clunky, so, packaging up some > predefined and commonly used handlers as ikarus command-line > options is also a good thing. Because I can imagine all kinds of possibly desired handling, maybe Ikarus should only provide --exceptions-to-file, because how do we really know what other command-line-options handler modes should exist? Also, what should the debugger do for non-&serious exceptions? I suppose it should not enter the debugger and just print and return. -- : Derick ----------------------------------------------------------------
