| To: | pcp@xxxxxxxxxxx |
|---|---|
| Subject: | Re: [pcp] Hotproc fixes |
| From: | Ken McDonell <kenj@xxxxxxxxxxxxxxxx> |
| Date: | Wed, 29 Apr 2015 08:56:17 +1000 |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <553FE1BC.4070309@xxxxxxxxxxx> |
| References: | <5536A934.8040002@xxxxxxxxxxx> <5537A154.2090803@xxxxxxxxxx> <5537A3F3.5060204@xxxxxxxxxxx> <233739221.5258413.1429764654377.JavaMail.zimbra@xxxxxxxxxx> <55392BAB.3060101@xxxxxxxxxxx> <806884984.5885784.1429839438565.JavaMail.zimbra@xxxxxxxxxx> <553FE1BC.4070309@xxxxxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
On 29/04/15 05:38, Martins Innus wrote: ... In the course of this, I need an error I can use when someone feeds pmstore a bad config. The best I could find is PM_ERR_CONV which seems to be used elsewhere, is that correct? PM_ERR_CONV is probably the closest error code, although this is most frequently encountered in bad pmExtractValue() calls. Other alternatives might be PM_ERR_GENERIC (depending on what options you have for reporting the error, e.g. to the PMDA log file), else petition for a new error code by proposing a new macro PM_ERR_FOO and suitable text to be associated with it via pmErrStr(). The latter course of action is OK in cases where none of the existing errors provide a "reasonable" semantic match for the error in question, and is how the error codes have grown over time (about 25% of the current PM_ERR_* macros did not exist in PCP 1.0). |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | pcp-update pmdapostfix install fix, Lukas Berk |
|---|---|
| Next by Date: | Re: [pcp] JSON PMDA, Nathan Scott |
| Previous by Thread: | Re: [pcp] Hotproc fixes, Nathan Scott |
| Next by Thread: | Re: [pcp] Hotproc fixes, Martins Innus |
| Indexes: | [Date] [Thread] [Top] [All Lists] |