On Sunday, 5 October 2014 at 09:06:45 UTC, Paolo Invernizzi wrote:
> Oh, I think that here in Italy we outperform your country with that, as for sure we are the most bureaucratised country on the hearth.

Hah! In Norway parents sign evaluation of progress for 6 years old school children every 2 weeks due to a "quality reform". And and  all pupils are kept on the same level of progress so that nobody should feel left behind due to "social democracy principles"... In Italy you have Montesorri! Consider yourself lucky!

In Norway bureaucracy is a life style and the way of being. In northern Norway the public sector accounts for 38-42% of all employees.

In Norway the cost of living is so high that starting a business is a risky proposition unless the public sector is your customer base. :^)

Walter Bright <newshound2@digitalmars.com> wrote:
> On 10/4/2014 3:30 AM, Steven Schveighoffer wrote:
>> On 10/4/14 4:47 AM, Walter Bright wrote:
>>> On 9/29/2014 8:13 AM, Steven Schveighoffer wrote:
>>>> I can think of cases where it's programmer error, and cases where it's user error.
>>> 
>>> More carefully design the interfaces if programmer error and input error are conflated.
>>> 
>> 
>> You mean more carefully design File's ctor? How so?
> 
> You can start with deciding if random  binary data passed as a "file name" is legal input to the ctor or not.

I think it helps to see contracts as an informal extension to the type
system.
Ideally, the function signature would not allow invalid input at all. In
practice, that's not always possible and contracts are a less formal way to
specify the function signature. But conceptually they are still part of the
signature.

And of course (as with normal contract-less functions) you are always allowed to provide convenience functions with extended input validation. Those should then be based on the strict version.

For example take a constructor for an XML document class.
It could take the (unvalidated) file path as string parameter. Or a file
(validated that it exists) object. Or a stream (validated that it exists
and is already opened).
You can provide all three for convenience, but I think it's still good
design to provide three _different_ functions.
Contracts are not a magical tool to provide you all three variants in one
function depending somehow on the needs of the caller.

Tobi

"Paolo Invernizzi" <paolo.invernizzi@no.address> wrote:
> And guess it, here the buildings made by ancient romans are still "up and running", while we have schools building made in the '90 that come down at every earthquake...

All the bad buildings from the ancient romans already came down while the last 2000 years. The best 1% survived.

Tobi

Am Fri, 03 Oct 2014 21:35:01 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2014-10-03 14:36, David Nadlinger wrote:
> 
> > you are saying that specific exceptions were replaced by enforce? I can't recall something like this happening.
> 
> I have no idea about this but I know there are a lot of "enforce" in Phobos and it sees to be encouraged to use it. Would be really sad if specific exceptions were deliberately replaced with less specific exceptions.

Nice, finally someone who actually wants to discern Exception
types. I'm always at a loss as to what warrants its own
exception type. E.g. when looking at network protocols, would
a 503 be a NetworkException, a HTTPException or a
HTTPInternalServerErrorException ?
Where do *you* wish libraries would differentiate?
Or does it really come down to categories like "illegal
argument", "division by zero", "null pointer", "out of memory"
for you?

-- 
Marco

Am Sat, 04 Oct 2014 13:12:43 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 10/4/2014 3:30 AM, Steven Schveighoffer wrote:
> > On 10/4/14 4:47 AM, Walter Bright wrote:
> >> On 9/29/2014 8:13 AM, Steven Schveighoffer wrote:
> >>> I can think of cases where it's programmer error, and cases where it's user error.
> >>
> >> More carefully design the interfaces if programmer error and input error are conflated.
> >>
> >
> > You mean more carefully design File's ctor? How so?
> 
> You can start with deciding if random  binary data passed as a "file name" is legal input to the ctor or not.

In POSIX speak [1] a file name consisting only of A-Za-z0-9.,-
is a "character string" (a portable file name) whereas anything
not representable in all locales is just a "string".
Locales' charsets are required to be able to represent
A-Za-z0-9.,- but may use a different mapping than ASCII for
that. Only the slash '/' must have a fixed value of 0x2F.

From that I conclude, that File() should open files by ubyte[]
exclusively to be POSIX compliant.

This is the stuff that's frustrating me much about POSIX. It
practically makes it impossible to write correct code. Even Qt
and Gtk+ settled for the system locale and UTF-8 respectively
as the assumed I/O charset for all file names, although each
file system could be mounted in a different charset. E.g.
CD-ROMs in ISO charset.
Windows does much better by offering Unicode versions on top
of the "ANSI" functions.
The only fix I see for POSIX is to deprecate all other locales
except UTF-8 at some point.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_267

-- 
Marco

On Saturday, 4 October 2014 at 19:36:02 UTC, Walter Bright wrote:
> On 10/4/2014 9:16 AM, Sean Kelly wrote:
>> On Saturday, 4 October 2014 at 09:18:41 UTC, Walter Bright wrote:
>>>
>>> Threads are not isolated from each other. They are not. Not. Not.
>>
>> Neither are programs that communicate in some fashion.
>
> Operating systems typically provide methods of interprocess communication that are robust against corruption, such as pipes, message passing, etc. The receiving process should regard such input as "user/environmental input", and must validate it. Corruption in it would not be regarded as a logic bug in the receiving process (unless it failed to check for it).
>
> Interprocess shared memory, though, is not robust.
>
>
>
>> I'll grant that the
>> possibility of memory corruption doesn't exist in this case (a problem unique to
>> systems languages like D), but system corruption still does.  And I absolutely
>> agree with you that if memory corruption is ever even suspected, the process
>> must immediately halt.  In that case I wouldn't even throw an Error, I'd call
>> exit(1).
>
> System corruption is indeed a problem with this type of setup. We're relying here on the operating system not having such bugs in it, and indeed OS vendors work very hard at preventing an errant program from corrupting the system.
>
> We all know, of course, that this sort of thing happens anyway. An even more robust system design will need a way to deal with that, and failure of the hardware, and failure of the data center, etc.
>
> All components of a reliable system are unreliable, and a robust system needs to be able to recover from the inevitable failure of any component. This kind of thinking needs to pervade the initial system design from the ground up, it's hard to tack it on later.

This is not different from fiber or thread based approach. If one uses only immutable data for inter-thread communications (== does not use inter-process shared memory) same gurantees and reasoning come. And such design allows for many data optimizations hard or impossible to do with process-based approach.

There is no magic solution that does not allow to screw up in 100% of cases whatever programmer does. Killing process is pragmatical default but not a pragmatical silver bullet and from pure theoretical point of few it has no advantages over killing the thread/fiber - it is all about chances of failure, not preventing it.

Same in Erlang - some failure warrant killing the runtime, some only specific process. It is all about the context and programmer should decide what is best approach for any specific program. I am fine with non-default being hard but I want it to be still possible within legal language restricions.

On 10/5/14, 8:08 AM, Marco Leise wrote:
> Nice, finally someone who actually wants to discern Exception
> types. I'm always at a loss as to what warrants its own
> exception type. E.g. when looking at network protocols, would
> a 503 be a NetworkException, a HTTPException or a
> HTTPInternalServerErrorException ?
> Where do*you*  wish libraries would differentiate?
> Or does it really come down to categories like "illegal
> argument", "division by zero", "null pointer", "out of memory"
> for you?

That reflects my misgivings about using exception hierarchies for error kinds as well. -- Andrei

On 2014-10-05 17:08, Marco Leise wrote:

> Nice, finally someone who actually wants to discern Exception
> types. I'm always at a loss as to what warrants its own
> exception type.

Yeah, that can be quite difficult. In the end, if you have a good exception hierarchy I don't think it will hurt to have many different exception types.

> E.g. when looking at network protocols, would
> a 503 be a NetworkException, a HTTPException or a
> HTTPInternalServerErrorException ?

For this specific case I would probably have one general exception for all HTTP error codes.

> Where do *you* wish libraries would differentiate?

I would like to have as specific exception type as possible. Also a nice hierarchy of exception when catching a specific exception is not interesting. Instead of just a FileException there could be FileNotFoundException, PermissionDeniedExcepton and so on.

> Or does it really come down to categories like "illegal
> argument", "division by zero", "null pointer", "out of memory"
> for you?
>

-- 
/Jacob Carlborg

On Sun, 5 Oct 2014 17:44:31 +0200
Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> From that I conclude, that File() should open files by ubyte[]
> exclusively to be POSIX compliant.
and yet there is currently no way in hell to open file with non-utf8 name with hardcoded name and without ugly hacks with File("..."). and ubyte will not help here, as D has no way to represent non-utf8 string literal without unmaintainable shit like "\xNN".

and speaking about utf-8: for strings we at least have a hack, and for
shebangs... nothing. nada. ничего. locale settings? other encodings? who
needs that, there CAN'T be non-utf8 shebangs. OS interoperability? it's
overhyped, there is only two kinds of OSes: those which are D-compatible
and bad. changing your locale to non-utf8 magically turns your OS to
bad, D will not try to interoperate with it anymore.

On 10/5/14, 8:56 AM, Jacob Carlborg wrote:
> I would like to have as specific exception type as possible. Also a nice
> hierarchy of exception when catching a specific exception is not
> interesting. Instead of just a FileException there could be
> FileNotFoundException, PermissionDeniedExcepton and so on.

Exceptions are all about centralized error handling. How, and how often, would you handle FileNotFoundException differently than PermissionDeniedException?

Andrei