On 02/10/14 01:19, David Nadlinger wrote:

> What are you referring to specifically? Compared to Tango, yes, Phobos
> might have a lot fewer concrete exception types. But I don't recall
> actually eliminating existing ones.

It happens implicitly when using "enforce". By default it will throw an instance of Exception. In most cases I don't think the developer bothers with specifying a specific exception type.

I really, really hate this. It makes it basically impossible to do any form of error handling correctly. I think Exception should be an interface or abstract class.

-- 
/Jacob Carlborg

On 01/10/14 21:57, Steven Schveighoffer wrote:

> ./progThatExpectsFilename ""
>
> -Steve

It's the developer's responsibility to make sure a value like that never reaches the "File" constructor. That is, the developer of the "progThatExpectsFilename" application that uses "File". Not the developer of "File".

Although, I don't see why you shouldn't be able to pass an empty string to "File". You'll just get an exception, "cannot open file ''". This is exactly what happens in Bash:

$ echo "asd" > ""
-bash: : No such file or directory

-- 
/Jacob Carlborg

On Monday, 29 September 2014 at 03:04:11 UTC, Walter Bright wrote:
> You've clearly got a tough job to do, and I understand you're doing the best you can with it. I know I'm hardcore and uncompromising on this issue, but that's where I came from (the aviation industry).
>
> I know what works (airplanes are incredibly safe) and what doesn't work (Toyota's approach was in the news not too long ago). Deepwater Horizon and Fukushima are also prime examples of not dealing properly with modest failures that cascaded into disaster.

Do you interpret airplane safety right? As I understand, airplanes are safe exactly because they recover from assert failures and continue operation. Your suggestion is when seat 2A creaks, shut down the whole airplane. In reality airplanes continue to operate until there's zero physical resource to operate. Fukushima caused disaster because it didn't try to handle failure. But this is your idea that one can do nothing meaningful on failure, and Fukushima did just that: nothing.

Termination of the process is the safe default, especially in the case of client software, but servers should probably terminate failed request, gracefully clean up and continue operation, like airplanes.

On 03/10/14 13:27, Kagamin wrote:

> Do you interpret airplane safety right? As I understand, airplanes are
> safe exactly because they recover from assert failures and continue
> operation. Your suggestion is when seat 2A creaks, shut down the whole
> airplane. In reality airplanes continue to operate until there's zero
> physical resource to operate.

I have no idea of airplane works but I think Walter usual says they have at least three backup systems. If one system fails, shut it down and switch to the backup.

-- 
/Jacob Carlborg

On Thursday, 2 October 2014 at 06:39:17 UTC, Jacob Carlborg wrote:
> On 02/10/14 01:19, David Nadlinger wrote:
>
>> What are you referring to specifically? Compared to Tango, yes, Phobos
>> might have a lot fewer concrete exception types. But I don't recall actually eliminating existing ones.
>
> It happens implicitly when using "enforce".

I'm well aware of that. But as

On Wednesday, 1 October 2014 at 23:00:41 UTC, Sean Kelly wrote:
> ...while in Phobos, most of the subtyped exceptions were
> eliminated a while back in favor of just always throwing
> Exception.

you are saying that specific exceptions were replaced by enforce? I can't recall something like this happening.

David

On Friday, 3 October 2014 at 12:16:30 UTC, Jacob Carlborg wrote:
> On 03/10/14 13:27, Kagamin wrote:
>
>> Do you interpret airplane safety right? As I understand, airplanes are
>> safe exactly because they recover from assert failures and continue
>> operation. Your suggestion is when seat 2A creaks, shut down the whole airplane. In reality airplanes continue to operate until there's zero physical resource to operate.
>
> I have no idea of airplane works but I think Walter usual says they have at least three backup systems. If one system fails, shut it down and switch to the backup.

My point, and I think Kagamin's as well, is that the entire plane is a system and the redundant internals are subsystems.  They may not share memory, but they are wired to the same sensors, servos, displays, etc.  Thus the point about shutting down the entire plane as a result of a small failure is fair.

On Friday, 3 October 2014 at 15:43:59 UTC, Sean Kelly wrote:
> My point, and I think Kagamin's as well, is that the entire plane is a system and the redundant internals are subsystems.  They may not share memory, but they are wired to the same sensors, servos, displays, etc.  Thus the point about shutting down the entire plane as a result of a small failure is fair.

An airplane is a bad analogy for a regular server. You have redundant backups everywhere and you are not allowed to take off at the smallest sign of deviation from normal operation. You will never see D in a fighter jet (and you can probably not fly it without the controller in operation either, your only choice is to send the plane into the ocean and escape in a parachute).

I think Walter forgets that you ensure integrity of a complex system of servers by utilizing a rock solid proven transaction database/task-scheduler for handling all critical information. If that fails, you probably should shut down everything, roll back to the last backup and reboot.

But you don't shut down a restaurant because the waiter forgets to write down an order every once in a while, you shut it down if the kitchen is unsuitable for preparing food. After sanitizing the kitchen you open the restaurant again. You also don't fire the sloppy waiter until you have a better waiter at hand…

On 29/09/14 02:09, Walter Bright via Digitalmars-d wrote:
> If the program has entered an unknown state, its behavior from then on cannot be
> predictable. There's nothing I or D can do about that. D cannot officially
> endorse such a practice, though D being a systems programming language it will
> let you do what you want.
>
> I would not even consider such a practice for a program that is in charge of
> anything that could result in injury, death, property damage, security breaches,
> etc.

I think I should clarify that I'm not asking you to say "I endorse catching Errors".  Your point about systems responsible for the safety of people or property is very well made, and I'm fully in agreement with you about this.

What I'm asking you to consider is a use-case, one that I picked quite carefully.  Without assuming anything about how the system is architected, if we have a telephone exchange, and an Error occurs in the handling of a single call, it seems to me fairly unarguable that it's essential to avoid this bringing down everyone else's call with it.  That's not simply a matter of convenience -- it's a matter of safety, because those calls might include emergency calls, urgent business communications, or any number of other circumstances where dropping someone's call might have severe negative consequences.

As I'm sure you realize, I also picked that particular use-case because it's one where there is a well-known technological solution -- Erlang -- which has as a key feature its ability to isolate different parts of the program, and to deal with errors by bringing down the local process where the error occurred, rather than the whole system.  This is an approach which is seriously battle-tested in production.

As I said, I'm not asking you to endorse catching Errors in threads, or other gross simplifications of Erlang's approach.  What I'm interested in are your thoughts on how we might approach resolving the requirement for this kind of stability and localization of error-handling with the tools that D provides.

I don't mind if you say to me "That's your problem" (which it certainly is:-), but I'd like it to be clear that it _is_ a problem, and one that it's important for D to address, given its strong standing in the development of super-high-connectivity server applications.

On Friday, 3 October 2014 at 16:11:00 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 3 October 2014 at 15:43:59 UTC, Sean Kelly wrote:
>> My point, and I think Kagamin's as well, is that the entire plane is a system and the redundant internals are subsystems.  They may not share memory, but they are wired to the same sensors, servos, displays, etc.  Thus the point about shutting down the entire plane as a result of a small failure is fair.
>
> An airplane is a bad analogy for a regular server. You have redundant backups everywhere and you are not allowed to take off at the smallest sign of deviation from normal operation.

That depends on design (logic). Ever heard of this?

http://www.reddit.com/r/programming/comments/1ax0oa/how_kdes_1500_git_repositories_almost_were_lost/


> I think Walter forgets that you ensure integrity of a complex system of servers by utilizing a rock solid proven transaction database/task-scheduler for handling all critical information. If that fails, you probably should shut down everything, roll back to the last backup and reboot.

I agree with Walter wholeheartedly. If I get him correctly he speaks about distinction between the program logic and input errors. Not about recovery strategies/decisions.

> But you don't shut down a restaurant because the waiter forgets to write down an order every once in a while, you shut it down if the kitchen is unsuitable for preparing food. After sanitizing the kitchen you open the restaurant again. You also don't fire the sloppy waiter until you have a better waiter at hand…

Let me play the game of finding analogies ;)
IMO, an exception is more suitable for the analogy with waiter and dirty kitchen.
A logic error would be a case when you think you are running a garage but suddenly you noticed your stuff is selling meals and is wearing chef's uniforms.

Piotrek

On 10/3/2014 10:00 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 29/09/14 02:09, Walter Bright via Digitalmars-d wrote:
>> If the program has entered an unknown state, its behavior from then on
>> cannot be
>> predictable. There's nothing I or D can do about that. D cannot
>> officially
>> endorse such a practice, though D being a systems programming language
>> it will
>> let you do what you want.
>>
>> I would not even consider such a practice for a program that is in
>> charge of
>> anything that could result in injury, death, property damage, security
>> breaches,
>> etc.
>
> I think I should clarify that I'm not asking you to say "I endorse
> catching Errors".  Your point about systems responsible for the safety
> of people or property is very well made, and I'm fully in agreement with
> you about this.
>
> What I'm asking you to consider is a use-case, one that I picked quite
> carefully.  Without assuming anything about how the system is
> architected, if we have a telephone exchange, and an Error occurs in the
> handling of a single call, it seems to me fairly unarguable that it's
> essential to avoid this bringing down everyone else's call with it.
> That's not simply a matter of convenience -- it's a matter of safety,
> because those calls might include emergency calls, urgent business
> communications, or any number of other circumstances where dropping
> someone's call might have severe negative consequences.
>
> As I'm sure you realize, I also picked that particular use-case because
> it's one where there is a well-known technological solution -- Erlang --
> which has as a key feature its ability to isolate different parts of the
> program, and to deal with errors by bringing down the local process
> where the error occurred, rather than the whole system.  This is an
> approach which is seriously battle-tested in production.
>
> As I said, I'm not asking you to endorse catching Errors in threads, or
> other gross simplifications of Erlang's approach.  What I'm interested
> in are your thoughts on how we might approach resolving the requirement
> for this kind of stability and localization of error-handling with the
> tools that D provides.
>
> I don't mind if you say to me "That's your problem" (which it certainly
> is:-), but I'd like it to be clear that it _is_ a problem, and one that
> it's important for D to address, given its strong standing in the
> development of super-high-connectivity server applications.

The part of Walter's point that is either deliberately overlooked or somewhat misunderstood here is the notion of a fault domain.  In a typical unix or windows based environment, it's a process.  A fault within the process yields the aborting of the process but not all processes.  Erlang introduces within it's execution model a concept of a process within the higher level notion of the os level process.  Within the erlang runtime it's individual processes run independently and can each fail independently.  The erlang runtime guarantees a higher level of separation than a typical threaded java or c++ application.  An error within the erlang runtime itself would justifiably cause the entire system to be halted.  Just as within an airplane, to use Walter's favorite analogy, the seat entertainment system is physically and logically separated from flight control systems thus a fault within the former has no impact on the latter.

So, where you have domains which must not impact each other, you reach for tools that allow complete separation such that faults within one CANNOT impact the other.  You don't leave room for 'might not'.

Later,
Brad