As the title says. :-)
I mean
Mailing lists / fpc-pascal / 2010-05
Does FPC has consts of portable OS error codes?
9 messages · 5 people ·
- Bihar Anwar 5
- Jonas Maebe 1
- leledumbo 1
- Marco van de Voort 1
- Tomas Hajny 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
I mean, for example, are there something like:
- fpcError_ERROR_PATH_NOT_FOUND = ESysENOENT in UNIX fpcError_ERROR_PATH_NOT_FOUND = ERROR_PATH_NOT_FOUND in Windows
- fpcERROR_FILENAME_EXCED_RANGE = ESysENAMETOOLONG in UNIX fpcERROR_FILENAME_EXCED_RANGE = ERROR_FILENAME_EXCED_RANGE in Windows
- etc.
Something like this one: https://libxpl.arsoft.homeip.net/browser/trunk/errormap/xplErrorMap.cpp?rev=70
As the title says. :-) I mean
Bihar Anwar wroteAs the title says. :-)
No, it doesn't.
Jonas
Something like this one: https://libxpl.arsoft.homeip.net/browser/trunk/errormap/xplErrorM…
Bihar Anwar wroteSomething like this one: https://libxpl.arsoft.homeip.net/browser/trunk/errormap/xplErrorMap.cpp?rev=70
I don't think we have platform independent (named) constants defined, but as you probably know, common error code _values_ are defined for our RTL as documented in chapter "Run time errors" in our Users' Guide.
Tomas
No, it doesn't. Jonas
Jonas Maebe on May 12, 2010 2:32:18 PM
Bihar Anwar wrote> As the title says. :-) No, it doesn't.
Any reason for that? or it is not implemented yet?
In our previous episode, Bihar Anwar said:
Show quoted text 7 lines
On 12 May 2010, at 05:53, Bihar Anwar wrote:
>> As the title says. :-)
> No, it doesn't.
Any reason for that? or it is not implemented yet?
FPC does not support abstraction of operating system errorcodes, and doesn't plan to.
The experiences in this regard (e.g. with the DOS unit) were not exactly positive.
Note that the fact that some header tries to hapzardly try to implement this for just two platforms doesn't prove this is universally possible.
Jonas Maebe on May 12, 2010 2:32:18 PM Any reason for that? or it is not implemented yet?
Any reason for that? or it is not implemented yet?
For me: it's not required. The purpose of error code is to provide information so we can handle it correctly, or at the simplest case, to display to user what has happened. For the first one, usually errors in FPC generate exception, you can handle that instead. For the second, a combination of GetLastOSError and SysErrorMessage provides what's needed.
View this message in context: http://old.nabble.com/Does-FPC-has-consts-of-portable-OS-error-codes--tp28531773p28533509.html
Sent from the Free Pascal - General mailing list .
leledumbo onMay 12, 2010 3:58:09 PM
Any reason for that? or it is not implemented yet? For the first one, usually errors in FPCgenerate exception, you can handle that instead.
Yes, as you said "usually", it is not "always". For example, FindFirst() and FindNext return OS dependent error code.
For the second, acombination of GetLastOSError and SysErrorMessage provides what's needed.
In my case, this is not something I want.
I want to handle "trivial errors" (e.g. ERROR_ACCESS_DENIED, ERROR_NOT_READY, etc.) differ from "fatal errors".
Trivial errors will allow users to retry the failed operation.