Recent

Author Topic: General / Generic Error Handling  (Read 8988 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11444
  • FPC developer.
Re: General / Generic Error Handling
« Reply #15 on: September 01, 2017, 07:41:13 pm »
Marco has lost me too... :D This was a design goal for FPC: TP compatibility. Which it is, apart from some 16/32 bit niggles.

Just look at the Delphi help, and specify which part FPC doesn't support.

ASerge

  • Hero Member
  • *****
  • Posts: 2240
Re: General / Generic Error Handling
« Reply #16 on: September 01, 2017, 08:12:09 pm »
I don't quite understand their comment about "Low Level" either
I do not know the function OpenFile. Only SysUtils.FileOpen

Low level:
var H: THandle; H := FileOpen(...);
The RTL does not check the result, nor does it handle the errors. You have to do it yourself.

High level (classic old style)
var F: File; AssignFile(F...); Reset(F);
Inside it calls something like FileOpen, saves the result to the System.InOutRes variable. If it's incorrect, in the case of the {$I+} state, throws an exception.

High level (new style)
var S: TFileStream; S := TFileStream.Create(...);
Inside it calls something like FileOpen, checks the result. If it's incorrect get an error message from the system and throws an exception.

joho

  • Jr. Member
  • **
  • Posts: 69
  • Joaquim Homrighausen
    • ~/JoHo
Re: General / Generic Error Handling
« Reply #17 on: September 02, 2017, 07:04:53 am »
Sorry if I mistyped the name ...  :)

Well, I guess I'll just have to decide between porting my generic I/O stuff first and then roll with that instead, or using "undocumented stuff in FPC", or using "traditional and documented pascal I/O".

Handle based I/O makes more sense to me, whether or not the "handle" is an integer or an object reference, and I've never been a fan of TP's traditional I/O handling.

Thanks everyone for responding. I'm not trying to sound ungrateful, I'm just trying to make sense of best practice, etc.

joho

  • Jr. Member
  • **
  • Posts: 69
  • Joaquim Homrighausen
    • ~/JoHo
Re: General / Generic Error Handling
« Reply #18 on: September 02, 2017, 07:21:06 am »
GetLastOSError is interesting though. That very much looks like C-style "errno" and is properly updated when, for example, FileOpen () fails. Maybe I should continue studying the RTL sources instead :)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11444
  • FPC developer.
Re: General / Generic Error Handling
« Reply #19 on: September 02, 2017, 10:30:28 am »
GetLastOSError is interesting though. That very much looks like C-style "errno" and is properly updated when, for example, FileOpen () fails. Maybe I should continue studying the RTL sources instead :)

Afaik getlastoserrror is either FPC's internal errno (on *nix) or just getlastwinerror function on windows. However the problem is that that assumes fileopen is open call, error results can be read always and multiple times AND the result will be OS dependent again.

joho

  • Jr. Member
  • **
  • Posts: 69
  • Joaquim Homrighausen
    • ~/JoHo
Re: General / Generic Error Handling
« Reply #20 on: September 03, 2017, 06:49:54 am »
I don't mind if "errno" is OS dependant. I have code to map the DOS, OS/2 and Windows error codes into something generic. Some codes don't exist on some OSs, and that's OK too. I haven't been able to locate where FileOpen calls the OS though ... (in the RTL sources I mean), but I will keep looking :)

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: General / Generic Error Handling
« Reply #21 on: September 03, 2017, 07:19:20 am »
@joho:
Inside sysutils (depends on platform where this file is located in source-tree), you can find fileOpen. For windows for example it reads:
Code: Pascal  [Select][+][-]
  1. Function FileOpen (Const FileName : unicodestring; Mode : Integer) : THandle;
  2. begin
  3.   result := CreateFileW(PWideChar(FileName), dword(AccessMode[Mode and 3]),
  4.                        dword(ShareModes[(Mode and $F0) shr 4]), nil, OPEN_EXISTING,
  5.                        FILE_ATTRIBUTE_NORMAL, 0);
  6.   //if fail api return feInvalidHandle (INVALIDE_HANDLE=feInvalidHandle=-1)
  7. end;

 

TinyPortal © 2005-2018