April 17, 2005
On Sun, 17 Apr 2005 11:09:32 -0700, Walter <newshound@digitalmars.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opspc69zdb23k2f5@nrage.netwin.co.nz...
>> Ok, so what do you think of this solution?
>> Other peoples input would be appreciated also.
>
> I appreciate the effort you've put into this.

No problem.

> What's wrong with the setup in 0.121 Phobos?

Everyone who wants to return a system error code/string has to copy the code you've used in FileException (for example). Not too onerous, but not perfect.

Did you see the thread on exception chaining?

The idea was Exception would have a constructor like:
  this(char[] msg, Object cause) {
  }

Allowing any exception to refer to a previous exception as the cause of the current exception.

Using that, making a SystemException class, passing that as the cause would make future use of SystemException really easy i.e.

//if errno is to be used
new FooBarException("foobar failed", new ErrnoException());

//if GetLastError is to be used
new FooBarException("foobar failed", new WindowsException());

//if WSAGetLastError is to be used
new FooBarException("foobar failed", new WindowsException(WSAGetLastError()));


> Why try to force a merge?

Actually, you have a point, there is no need to merge the error codes to achieve the stuff above. Let me try again.


> Code that will generate a C errno is always going to be very different from
> code that generates a Windows getLastError(). Keep them parallel and distinct,
> and there shouldn't be any confusion about it.

Ok. I believe I have an idea in mind. One thing I will mention is that part of my intent was to have a common base class allowing you to catch both ErrnoException and WindowsException problems as SystemException, allowing system independant catch calls, eg.

try {
}
catch(SystemException e) {
}


> Your method reserves the 'CUSTOM' value range. What if the user's
> application needs a custom value range? They can't use D.

'CUSTOM' is the range intended for users to use. I've never defined custom error codes so I wasn't sure how to give an example of how to use 'CUSTOM'.


> What if a D app
> links to a C dll that uses those values? It'll fail in mysterious ways.

Wouldn't the DLL have to expose the error codes and error strings, or provide it's own method for getting an error string from an error code? If so, I'd imagine a new D <DLLNAME>Exception class would be written to handle them. eg.

class <DLLNAME>Exception : Exception {
  this(uint code)
  {
    super(<dll_function_to_get_error_string>(code));
  }
}

Regan
April 17, 2005
The only problem being that sysErrorString deals with GetLastError codes on windows and errno codes on linux, but not errno codes on Windows which do not map to GetLastError codes and are returned for other things.

I have a plan. Gimme a little time to write and post it.

Regan

On Sun, 17 Apr 2005 14:21:11 -0400, Ben Hinkle <ben.hinkle@gmail.com> wrote:
>
> "Walter" <newshound@digitalmars.com> wrote in message
> news:d3sk8r$qgo$1@digitaldaemon.com...
>>
>> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
>> news:d3r0cv$2nfb$1@digitaldaemon.com...
>>> Naturally I'd prefer not to duplicate the definition of FooException in
>> the
>>> different versions and instead have one definition that calls a common
>>> errno->string function (eg sysErrorString). It's cleaner IMO. But it's
>> your
>>> call...
>>
>> But there can't be a common errno->string function, as C errno and Windows
>> errno coexist, but are different.
>
> I'm not sure what you mean by different. They have different errors and
> numbers and strings but the concept of mapping an error code to a string is
> independent of all that. More specifically, instead of std.file looking like
>
> version(Windows) {
>   class FileException {
>      ...10 lines of code or so ...
>      this(char[] x,uint errno) {
>       this(x,sysErrorString(errno));
>       ...
>     }
>   }
>   ... Windows code ...
> } else version (linux) {
>   class FileException {
>      ...same 10 lines of code as above ...
>      this(char[] x,uint errno) {
>       char* s = strerror(errno);
>       this(x,<stringify>(s));
>       ...
>     }
>   }
>   ... Linux code ...
> }
>
> it should look like
>
>   class FileException {
>      ...10 lines of code or so ...
>      this(char[] x,uint errno) {
>       this(x,sysErrorString(errno));
>       ...
>     }
>   }
>  ... rest of std.file ...
>
> and sysErrorString looks like
>
> char[] sysErrorString(int errno) {
>   version (Windows) {
>     .. content of existing std.windows.syserror ...
>   } else {
>       char* s = strerror(errno);
>       return <stringify>(s);
>   }
> }
>
> It's just taking the exact same code you have and rearranging it to avoid
> code duplication. Everything else in std.file is exactly the same. The
> Windows code passes the result of GetLastError to the FileException ctor and
> the Linux version passes getErrno(); Why have every module that wants to use
> a system error copy and paste code? It's begging for the errno->string
> abstraction IMO.
>
>

April 17, 2005
On Sun, 17 Apr 2005 10:51:45 -0700, Walter <newshound@digitalmars.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opspczbht823k2f5@nrage.netwin.co.nz...
>> On Sat, 16 Apr 2005 20:07:24 -0700, Walter <newshound@digitalmars.com>
>> wrote:
>> > "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
>> > news:d3r0cv$2nfb$1@digitaldaemon.com...
>> >> Naturally I'd prefer not to duplicate the definition of FooException  
>> in
>> > the
>> >> different versions and instead have one definition that calls a  
>> common
>> >> errno->string function (eg sysErrorString). It's cleaner IMO. But  
>> it's
>> > your
>> >> call...
>> >
>> > But there can't be a common errno->string function, as C errno and
>> > Windows errno coexist, but are different.
>>
>> What do you mean by "Windows errno"? Are you referring to GetLastError()?
>
> That's right. You see, we're already confused about which error number we're talking about. That's why they can't be the same function <g>.

I was asking for clarification because windows has "errno" and "GetLastError" and you used the former to describe the latter. Bad Walter. :)

Regan
April 17, 2005
Here is attempt #2, or is it #3.

Goals:
- Provide a base class SystemException that can be caught to catch all OS
level exceptions regardless of OS.
- Make handling of system error codes easy for future exception writers.
- Provide both errno and GetLastError handling (on windows).
- Don't merge error codes for errno and GetLastError handling (on windows).

It is intended these classes be used with exception chaining. eg.

throw new FooException("custom text", new ErrnoException());
throw new FooException("custom text", new WindowsException());

Regan

April 17, 2005
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3u9er$25ev$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:d3sk8r$qgo$1@digitaldaemon.com...
> > But there can't be a common errno->string function, as C errno and
Windows
> > errno coexist, but are different.
>
> I'm not sure what you mean by different. They have different errors and numbers and strings but the concept of mapping an error code to a string
is
> independent of all that.

What are you going to do with Windows code that calls C's read() function?


April 17, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message news:opspebv4zg23k2f5@nrage.netwin.co.nz...
> > Your method reserves the 'CUSTOM' value range. What if the user's application needs a custom value range? They can't use D.
>
> 'CUSTOM' is the range intended for users to use.

Yes. Not for systems tools like D <g>.


April 18, 2005
On Sun, 17 Apr 2005 15:50:47 -0700, Walter <newshound@digitalmars.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opspebv4zg23k2f5@nrage.netwin.co.nz...
>> > Your method reserves the 'CUSTOM' value range. What if the user's
>> > application needs a custom value range? They can't use D.
>>
>> 'CUSTOM' is the range intended for users to use.
>
> Yes. Not for systems tools like D <g>.

Yep. Which is why I redefined it to not include the values I needed for errno values.

Regan
April 18, 2005
Walter wrote:
> Focus is on fixing compiler issues, especially the bugs introduced with
> 0.120.
> 
> http://www.digitalmars.com/d/changelog.html

"Abstract class methods now cause the class to be abstract."

That's always worked in my experience.  So what's changed?

"Fixed a bug in the Windows version of seek() with files larger than uint.sizeof."

How strange that something would ever have been written that worked only on files up to 4 bytes....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.
April 18, 2005
"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:d40ns9$1dji$1@digitaldaemon.com...
> Walter wrote:
> "Abstract class methods now cause the class to be abstract."
>
> That's always worked in my experience.  So what's changed?

A couple of the abstract_nn cases in Dstress.


April 18, 2005
> "Fixed a bug in the Windows version of seek() with files larger than uint.sizeof."
>
> How strange that something would ever have been written that worked only on files up to 4 bytes....

hehe. you're right. I sent that to Walter and didn't even realize how silly that is. I should have said uint.max, of course. :-P