View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001970 | unreal | ircd | public | 2004-07-16 21:34 | 2018-05-01 17:02 |
| Reporter | Assigned To | syzop | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | wont fix | ||
| Summary | 0001970: Standardized return values | ||||
| Description | Looking through the code, the values returned by our command functions are very random. Most return 0, others return -1 on error, etc. I was thinking, maybe it would be a good idea to expand this? Like I'm thinking, we could remove some duplicate code. For example, consider the "insufficient parameters" error. Just about every command has one. Well, if we did, return RET_MOREPARAMS;, then we wouldn't need to have the sendto_one with the error, we could have the command loop check the return value, and if it returned RET_MOREPARAMS, then the command loop will display the error. That way, instead of having that sendto_one in 500 places, it's in just 1. This could (with some modifications to the command override system) also allow modules to detect things. Like for example, maybe I want to tack something onto the end of the /motd reply, however I don't want to do that if the MOTD was passed on to another server (hunt_server), so I check the return value to see if it is RET_SUCCESS. If it is, then I display my message. Some of the return values I thought of: RET_MOREPARAMS - triggers an ERR_NEEDMOREPARAMS RET_NEEDOPER - triggers an ERR_NOPRIVILEGES RET_NOACCESS - not a server/not a uline/etc. RET_ERROR - some other error occurred RET_HUNTED - the message was passed to another server RET_SUCCESS - the command succeeded I think that would make the code a bit cleaner. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Interesting idea... it would naturally take time for modules to catch up with such a new scheme... but I guess that's true of anything... Hope you don't mind if I give suggestions to add to the list... RET_NEEDCHANOPS - Send ERR_CHANOPRIVSNEEDED (or whatever its called) ? Good for dealing with MODE, KICK, TOPIC, PRIVMSG/NOTICE &/~ and anything else that requires chanops... Also, RET_BADTARGET for messages to a non-existant nick/channel/server? Though there are 3 seperate numerics that are needed, so maybe 3 seperate error codes (like RET_BADTARGET_NICK RET_BADTARGET_CHAN RET_BADTARGET_SERVER)? Of course, IIRC these require a parameter saying what wasn't found, so maybe this requires more than I'm thinking of... What other common error codes are there...? Also, it would be hard to make RET_MOREPARAMS apply to PRIVMSG/NOTICE since they have special "insufficient parameter" messages... "No recepient given" "No text to send" etc |
|
|
Bump. |
|
|
doubt this will ever be done -- closing |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-07-16 21:34 |
|
New Issue | |
| 2004-07-16 22:54 | aquanight | Note Added: 0007114 | |
| 2007-04-27 06:09 |
|
Note Added: 0013856 | |
| 2007-04-27 06:09 |
|
Status | new => feedback |
| 2015-08-08 17:52 | syzop | Severity | minor => feature |
| 2018-05-01 17:02 | syzop | Assigned To | => syzop |
| 2018-05-01 17:02 | syzop | Status | feedback => closed |
| 2018-05-01 17:02 | syzop | Resolution | open => wont fix |
| 2018-05-01 17:02 | syzop | Note Added: 0020121 |
