January 16, 2015
On Thursday, 15 January 2015 at 21:29:28 UTC, Tobias Müller wrote:
> In a well-designed interface, every function specifies all the errors that might happen.


BWAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA !
January 16, 2015
On Thursday, 15 January 2015 at 21:48:25 UTC, Tobias M wrote:
> Example:
> Creating a file: Throws if already exists.
> Creating a unique filename:
> Create file.1.exp
> Create file.2.exp
> Create file.3.exp
> ... until it succeeds.
> Here failure is expected and normal, still trial/error is the only option because a querying the file first is not safe.
>
> How can I (as the implementer of the "Create file" function) decide if a failure is actually expected or not?
> I can't, because I cannot foresee every use case of the function.
>
> *Especially* with environmental errors that caller has to decide what's an error and what not.
> You cannot just require certain environmental preconditions, because they can change unexpectedly.

auto create_unique_file() {
  for (uint i = 0;; i++) {
    auto name = make_name(i);
    if (file_exists(name)) continue;

    try {
      create_file(name);
      return name:
    } catch(FileAlreadyExistException e) { }
  }
}

You don't need 2 interfaces, the only time when the Exception is going to fire, is if the file is created between the file_exists check and the actual creation: almost never.
January 16, 2015
On Friday, 16 January 2015 at 00:48:57 UTC, deadalnix wrote:
> On Thursday, 15 January 2015 at 21:29:28 UTC, Tobias Müller wrote:
>> In a well-designed interface, every function specifies all the errors that might happen.
>
>
> BWAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA !

'tis true, unfortunately implementations don't match the spec...

But that ought to be machine verifiable. Shitty compilers.
January 16, 2015
On Fri, 16 Jan 2015 01:01:26 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Friday, 16 January 2015 at 00:48:57 UTC, deadalnix wrote:
> > On Thursday, 15 January 2015 at 21:29:28 UTC, Tobias Müller wrote:
> >> In a well-designed interface, every function specifies all the errors that might happen.
> >
> >
> > BWAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA !
> 
> 'tis true, unfortunately implementations don't match the spec...
> 
> But that ought to be machine verifiable. Shitty compilers.
so human must do all machine wants from him, until that machine is pleased? i like it. and i hate humans anyway, so it's fun to see them suffering.


January 16, 2015
On Friday, 16 January 2015 at 00:59:34 UTC, deadalnix wrote:
> auto create_unique_file() {
>   for (uint i = 0;; i++) {
>     auto name = make_name(i);
>     if (file_exists(name)) continue;
>
>     try {
>       create_file(name);
>       return name:
>     } catch(FileAlreadyExistException e) { }
>   }
> }
>
> You don't need 2 interfaces, the only time when the Exception is going to fire, is if the file is created between the file_exists check and the actual creation: almost never.

IMO, this example just shows that it's a bad idea to follow the "exceptions are for exceptional circumstances only" mantra too strictly. The call to `file_exists()` serves no other purpose than to make the exception truly exceptional, otherwise it's completely superfluous (well, aside from performance concerns, but these are implementation details). Simply leave it out and only rely on the exception, it really isn't evil.
January 16, 2015
>
> IMO, this example just shows that it's a bad idea to follow the "exceptions are for exceptional circumstances only" mantra too strictly. The call to `file_exists()` serves no other purpose than to make the exception truly exceptional, otherwise it's completely superfluous (well, aside from performance concerns, but these are implementation details). Simply leave it out and only rely on the exception, it really isn't evil.

1. Exception are too slow
2. They're used for exceptional cases only, they're fast enough for this
1. But look here, my file handling code might very well throw an exception, if the file already exists.

--> Use of a very slow operation, probably involving a spinning disk, at least a system call, to argue that exceptions are too slow does not convince me, sorry.
6 7 8 9 10 11 12 13 14 15 16
Next ›   Last »