| Type | Bug | Status | tested | Date | 4-May-2010 10:10 |
|---|---|---|---|---|---|
| Version | alpha 97 | Category | Error Handling | Submitted by | meijeru |
| Platform | All | Severity | minor | Priority | normal |
| Summary | Error made with code has correct type/id, the converse is not the case |
|---|---|
| Description |
A value of type error! can be made by specifying its CODE, which is a number that encodes the TYPE and ID components. Conversely, an error! value can also be made by specifying the TYPE and ID components, which should of course be compatible. If they are not, an error is raised. But even if they are, the CODE component contains a new number, not corresponding to the TYPE/ID combination and one higher than the highest defined one, as if this were a new kind of error. |
| Example code |
>> system/catalog/errors/Math
== make object! [
code: 400
type: "math error"
zero-divide: "attempt to divide by zero" ;; 400
overflow: "math or number overflow" ;; 401
positive: "positive number required" ;; 402
]
>> probe make error! [code: 400]
make error! [
code: 400
type: 'Math
id: 'zero-divide
arg1: none
arg2: none
arg3: none
near: none
where: none
]
** Math error: attempt to divide by zero
>> probe make error![type: 'Note id: 'zero-divide]
** Script error: invalid argument: [type: 'Note id: 'zero-divide]
>> probe make error![type: 'Math id: 'zero-divide]
make error! [
code: 403 ;; <<<<< new number
type: 'Math
id: 'zero-divide
arg1: none
arg2: none
arg3: none
near: none
where: none
]
** Math error: attempt to divide by zero
>> probe make error! [code: 403]
make error! [
code: 403
type: 'Math
id: none
arg1: none
arg2: none
arg3: none
near: none
where: none
]
** Math error: (improperly formatted error)
|
| Assigned to | n/a | Fixed in | alpha 108 | Last Update | 20-Oct-2010 03:33 |
|---|
| Comments | |
|---|---|
|
(0002299)
Carl 4-May-2010 20:26 |
Stated above: "A value of type error! can be made by specifying its CODE"
Actually, the plan has been to get away from using the numeric codes, because as we add errors, the codes change. So a 321 today may not be a 321 next week. Therefore, specification of error code to generate the error is not valid. That being said, we still have some work to do here. |
|
(0002303)
meijeru 4-May-2010 20:57 |
Yeah, but the errors with code < 100 are ONLY distinguishable by their code, aren't they?? |
|
(0002305)
BrianH 4-May-2010 21:05 |
That you can refer to errors with codes < 100 at all is a bug, specifically bugs #1509 and #1515. Worry more about fixing those bugs, than about working with pseudo-errors that you are supposed to be restricted from creating explicitly. |
|
(0002307)
meijeru 4-May-2010 21:21 |
You missed my point entirely. Errors as currently implemented occupy two 32 bits values: the first is 0 for errors with code < 100, and is an object pointer (i.e. "the object contained in the error", in Carl's way of saying) for code >= 100; the second is the code value itself. Thus getting away from the codes could be difficult... |
|
(0002310)
BrianH 4-May-2010 21:34 |
But not for any error values that you are supposed to be able to work with *in any way*. For unwinds (pseudo-errors with codes under 100) you are not supposed to see them, not to mold them, not to create them, not to change their codes, not in REBOL code.
Those codes could easily be internal values that you (the user) should never see, especially for unwinds. So there may not be a way for the *implementor* of R3 to get away from these codes, but *users* of R3 can be shielded from them with no difficulties. We're trying to get away from their use by user code, not their existence in some internal sense. |
|
(0002311)
meijeru 4-May-2010 22:37 |
OK, you have got a point there. In that case, if the user creates an error by TYPE and ID, there are three cases:
TYPE and ID are both existing but not compatible ==> some error should be raised to signal this, I suppose TYPE and ID are both existing and compatible ==> the proper error should be made (not the case now) either TYPE or ID is non-existent ==> in the absence of an entry in SYSTEM/CATALOG/ERRORS, what does one do: add it? |
|
(0002312)
BrianH 5-May-2010 01:21 |
Sure, ahead of time, once the protect bugs are fixed. |
|
(0002615)
BrianH 20-Oct-2010 03:33 |
As of alpha 108, code: still works, but type: and id: are checked against the catalog. An error is triggered if the type and id are specified and are not correct (a different error is triggered than the one you were trying to make and possibly trigger later). It is recommended that you use the type and id from now on, as the code can't be relied on to be consistent in the future, and will likely be deprecated. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 20-Oct-2010 03:33 | BrianH | Status | Modified | built => tested |
| 20-Oct-2010 03:33 | BrianH | Comment : 0002615 | Added | - |
| 22-Sep-2010 01:12 | carl | Status | Modified | reviewed => built |
| 22-Sep-2010 01:12 | carl | Fixedin | Modified | => alpha 108 |
| 1-Jul-2010 13:20 | BrianH | Comment : 0002310 | Modified | - |
| 5-May-2010 01:21 | BrianH | Comment : 0002312 | Added | - |
| 4-May-2010 23:25 | meijeru | Comment : 0002311 | Modified | - |
| 4-May-2010 22:37 | meijeru | Comment : 0002311 | Added | - |
| 4-May-2010 21:38 | BrianH | Comment : 0002310 | Modified | - |
| 4-May-2010 21:37 | BrianH | Comment : 0002310 | Modified | - |
| 4-May-2010 21:34 | BrianH | Comment : 0002310 | Added | - |
| 4-May-2010 21:21 | meijeru | Comment : 0002307 | Added | - |
| 4-May-2010 21:05 | BrianH | Comment : 0002305 | Added | - |
| 4-May-2010 20:57 | meijeru | Comment : 0002303 | Added | - |
| 4-May-2010 20:26 | carl | Status | Modified | submitted => reviewed |
| 4-May-2010 20:26 | carl | Code | Modified | - |
| 4-May-2010 20:26 | carl | Description | Modified | - |
| 4-May-2010 20:26 | carl | Comment : 0002299 | Added | - |
| 4-May-2010 10:10 | meijeru | Ticket | Added | - |