Opened 20 years ago
Closed 17 years ago
#792 closed defect (invalid)
psError should use strings instead of numeric error codes
| Reported by: | jhoblitt | Owned by: | jhoblitt |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | sys | Version: | 0.12.99 |
| Severity: | normal | Keywords: | |
| Cc: | rhl@… |
Description
So that new error codes can be registered at runtime without the hassel of
coordinating numeric error code ranges among different products. This should be
fairly efficent if implimented as a hash and potentally faster then the current
method of walking a list for all runtime registered types.
Change History (3)
comment:1 by , 20 years ago
| bug_group: | PSLib? |
|---|
comment:2 by , 20 years ago
It's not so much error codes allocated by us that I'm worried about it. My
concern is more about collisions between error codes assigned by 3rd parties.
Past experience with UID allocation range schemes has shown that collisions can
and will happen no matter who carefully one is. It's my gut feeling that the
current psError scheme is just a bit too fragile. Although, I don't have a
strong sense of what the right solution is.
I don't agree with your statement that it's not possible to classify error
strings. One possibility would be use a pseudo product hierarchy similar to
the one used by psTrace & psLog.
psErrorCode err = psErrLast();
if (psErrorClass(err, "psLib.db.dberror") {
psError("psLib.fatal", false, "fatal error");
...
}
ignore all database errors
psErrorCode err = psErrLast();
if (!psErrorClass(err, "psLib.db") {
...
}
Or we could turn it around so the severity of the error is at the root of the
tree.
ignore all but fatal errors
psErrorCode err = psErrLast();
if (!psErrorClass(err, "Fatal") {
...
}
comment:3 by , 17 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
we've decided to keep numeric error codes.

I'm not sure that this is a good idea. The numerical values (enums, actually) are
checked at compile time --- the idea is that we use classes of exception, rather
like values of errno. In fact, small integers are interpreted as legal errno values
and strerror() is used to return the error string.
If we use strings, we'll have no way of classifing error classes. In particular, we
want to be able to get an error return and decide to ignore it:
If we're worried about allocating blocks of errors, I can think of designs that make
this foolproof and simple.