UNTRAPPABLE ERROR!

** ERROR: refinements lines and binary are incompatible. Now I hadn't seen single line errors! of no type before so I tried this.....

** ERROR: refinements lines and binary are incompatible.

** ERROR: refinements lines and binary are incompatible.

USAGE: DISARM error DESCRIPTION: Returns the error value as an object. DISARM is a native value. ARGUMENTS: error -- (Type: error) I couldn't trap this error with DISARM & convert it to an error-object so I probed system/error to see if I could see what was going on but it also doesn't seem to contain this error! message. Therefore I concluded that the 'OPEN function mut be doing something like this internally..... my-open: func [ file [file!] /lines /binary ] [ if all [lines binary] [ print "** ERROR: refinements Lines and Binary Incompatible." halt ] print "continuing with function operations" ] The point here being that this error! string is written directly to standard output and does NOT appear to return error! values in the usual way as you might expect, this sort of behaviour SHOULD be changed immediately but please watch out for it. Has anybody else seen this problem or anything similar before? Cheers, Mark Dickson

That's because this is not a REBOL error!. It is an interpreter failure that bypasses the normal error mechanism. It is necessary in some fatal situations to avoid getting caught in "error loops". I don't see any reason in this particular situation though. We'll have a look... -- Holger Kruse [holger--rebol--com]

I think what you're doing is making a fatal assumption about the nature of errors in REBOL. REBOL can't do the same thing as, say, a C compiler otherwise it could report the /lines/binary error before the script even started. gcc can pick up things like "too many arguments" problems during the compilation process but REBOL interprets on the fly - it can't do that. Normal errors are "runtime exceptions" - incorrect values appearing somewhere and so on. These are non-fatal problems that can be overcome programatically via a try/disarm construct. They are "correct" programs which generate an exceptional result. The error you have hit upon is something more drastic - a low level interpreter exception. This simply can not be caught and handled because you're trying to tell the interpreter to do something that, while syntactically correct, is logically and physically incorrect. Do you know Java? Java has a very strange, but ultimately sensible, exception system: All subclasses of Exception must either be caught using a try{}catch(){} construct where they are thrown or the method in which the exception occurs must declare that it "throws" the exception and the handling is passed up to the next level in the program. There is an exception to this rule however: RuntimeExceptions do not have to be caught and the "throws" is not needed for them - they cover things like ArrayIndexOutOfBoundsException, NullPointerException and other "This was caused by a Bug" exceptions. These should generally not be caught as they indicate a serious - possibly unrecoverable - problem in your program. The situation in REBOL is similar - normal errors - Exceptions - can be caught and handled with impunity because they will often be intended or expected. They may indicate a problem has occured in the program, but it's a problem you expect and know how to fix. Interpreter RuntimeException errors - like the /lines/binary one - are an indication of a serious bug in your code that should stop the script working until it is fixed. Chris -- New sig in the works Explorer2260 Designer and Coder http://www.starforge.co.uk

I think what you're doing is making a fatal assumption about the nature of errors in REBOL. REBOL can't do the same thing as, say, a C compiler otherwise it could report the /lines/binary error before the script even started. gcc can pick up things like "too many arguments" problems during the compilation process but REBOL interprets on the fly - it can't do that. Normal errors are "runtime exceptions" - incorrect values appearing somewhere and so on. These are non-fatal problems that can be overcome programatically via a try/disarm construct. They are "correct" programs which generate an exceptional result. The error you have hit upon is something more drastic - a low level interpreter exception. This simply can not be caught and handled because you're trying to tell the interpreter to do something that, while syntactically correct, is logically and physically incorrect. Do you know Java? Java has a very strange, but ultimately sensible, exception system: All subclasses of Exception must either be caught using a try{}catch(){} construct where they are thrown or the method in which the exception occurs must declare that it "throws" the exception and the handling is passed up to the next level in the program. There is an exception to this rule however: RuntimeExceptions do not have to be caught and the "throws" is not needed for them - they cover things like ArrayIndexOutOfBoundsException, NullPointerException and other "This was caused by a Bug" exceptions. These should generally not be caught as they indicate a serious - possibly unrecoverable - problem in your program. The situation in REBOL is similar - normal errors - Exceptions - can be caught and handled with impunity because they will often be intended or expected. They may indicate a problem has occured in the program, but it's a problem you expect and know how to fix. Interpreter RuntimeException errors - like the /lines/binary one - are an indication of a serious bug in your code that should stop the script working until it is fixed. Chris -- New sig in the works Explorer2260 Designer and Coder http://www.starforge.co.uk

Hi Chris, I appreciate the analysis of Mark's reported problem. But I would like *all* errors to be trapped. Below is my "standard application wrapper" (shorn of error logging/reporting, restart code, etc). The idea is that the user never gets dumped into the Console no matter how bad the code I've foisted on them. Rebol [] Forever [ APPLICATIONERROR: copy [] If error? APPLICATIONERROR: try [ do %application.r ][ ALERTSTATUS: alert [join "It's fallen over!!!" [ "Please make a note of " "the cryptic stuff below and send it to ..., Thanks. " "=======================" mold disarm APPLICATIONERROR "=======================" ] ; join "Restart" "Exit" ] ; alert if not ALERTSTATUS [quit] ] ; if ] ; forever This code catches the situation where Application.r doesn't exist...But it won't catch the sort of Interpretor/Runtime errors that you describe. I know they shouldn't be there but if they are, it'd be nice not to need another error reporting mechanism. --Colin.