On Sunday, 5 October 2014 at 16:18:33 UTC, Andrei Alexandrescu wrote:
> 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

While precise formalization of the principle is hard I think this comment nails it in general. When defining exceptions hierarchies it makes sense to think about it in terms of "what code is likely to catch it and why?" and not "what this code should throw?". Dedicated exception type only makes sense if it is a common to catch it separately, any additional details can be stored as runtime field (like status code for HTTPStatusException)

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

> Would you agree that every time DMD reports a syntax error in user code, it should also include a stack trace of the DMD source code to where in DMD it reported the error?

Of course not. DMD is a compiler and it is part of its normal operation to have sophisticated code to report syntax errors. I distinguish between "expected" exceptions and "unexpected" exceptions.

Expected exceptions are those that occur due to validating user input or as part of handling documented error codes at the interface layer with external APIs.

Unexpected exceptions are those we don't handle explicitly because we don't expect them. Maybe because we think that code wont throw, since the input had been validated or a bug in an external library or laziness.

A FileNotFoundException can be the expected result of an "open
file" dialog with the user typing the name of a non-existent
file or the unexpected result of loading a static asset with
an index that is off-by-one (e.g. icon<idx>.bmp).
In the case of DMD, syntax errors are *expected* as part of
validating user input. And that's why it prints a single line
that can be parsed by IDEs to jump the the source.
Now to make things interesting, we also see *unexpected*
exceptions in DMD: internal compiler errors.

While expected exceptions are commonly handled with a simple message, unexpected exceptions are handled depending on application. In non-interactive applications like DMD they can all be AssertErrors that terminate the program. In interactive software like a video editor, someone might just have spent hours on editing and the user should be allowed to reason about the severity of the fault and decide to ignore the exception or quit the program. There are other solutions like logging and emailing the error to someone.

The example above, about the off-by-one when reading an icon is a typical case of an exception that you would want to investigate with an exception stack trace, but keep the program running.

-- 
Marco

Am Fri, 03 Oct 2014 10:38:21 -0700
schrieb Brad Roberts via Digitalmars-d
<digitalmars-d@puremagic.com>:

> 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.

And just like the Erlang runtime, the electrical components
could be faulty or operating beyond their limits and cause the
aircraft to shutdown.
http://www.dailymail.co.uk/news/article-2519705/Blaze-scare-BA-Jumbo-Serious-electrical-sparked-planes-flight-entertainment-system.html
http://en.wikipedia.org/wiki/Swissair_Flight_111
http://www.iasa.com.au/folders/sr111/747IFE-fire.htm

-- 
Marco

On 10/05/2014 05:35 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> 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"...

Aside from those 2 week evals (ouch!), the US isn't a whole lot different. US schools are still notoriously bureaucracy-heavy (just ask any school employee), and "No child left behind" is a big thing (at least, supposedly) while any advanced kids are capped at the level of the rest of their age group and forbidden from advancing at their own level (thus boring the shit out of them and seeding quite a few additional problems).

Partly, that level-capping is done because there's a prevalent (but obviously BS) belief that kids should be kept with others of the same age, rather than with others of the same level of development or even a healthy mix. But also, they call this capping of advanced students "Being fair to the *other* kids". Obviously US teachers have no idea what the word "fair" actually means. But then, in my experience, there's a LOT that US teachers don't know.

I blame both the teacher's unions (that's not intended as a statement on unions in general, BTW) and the complete and total lack of "logic" being part of the curriculum *they* were taught as kids (which is still inexcusably absent from modern curriculums).

> In Italy you have
> Montesorri! Consider yourself lucky!
>

US has a few of those too. They're constantly ridiculed (leave it to the US to blast anything that isn't group-think-compatible), but from what I've seen Montesorri's are at least less god-awful than US public schools. I almost went to one (but backed out since, by that point, it would have only been for one year - actually wound up with one of the best teachers I ever had that year, so it worked out fine in the end).

On 10/5/2014 8:35 AM, Dicebot wrote:
> I am fine with non-default being hard but I
> want it to be still possible within legal language restricions.

D being a systems language, you can without much difficulty do whatever works for you.

People do look to us for guidance, however.

The levels of programming mastery:

newbie: follow the rules because you're told to
master: follow the rules because you understand them
guru: break the rules because you understand their limitations

I'd be doing our users an injustice by not making sure they understand the rules before trying to break them.

On 10/5/2014 3:00 AM, Tobias Müller wrote:
> All the bad buildings from the ancient romans already came down while the
> last 2000 years. The best 1% survived.

Yay for survivorship bias!

Am Sun, 5 Oct 2014 19:04:23 +0300
schrieb ketmar via Digitalmars-d <digitalmars-d@puremagic.com>:

> 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.

There comes the day that you have to let Sputnik go and board
the ISS.
Still I and a others agree with you that Phobos should not
assume Unicode locales everywhere, no need to rant.

What I find difficult is to define just where in std.stdio the
locale transcoding has to happen. Java probably just wraps
a stream in a stream in a stream as usual, but in std.stdio it
is just a File struct that more or less directly writes to the
file descriptor. So my guess is, the transcoding has to happen
at an earlier stage. Next, when output is NOT a terminal you
typically want to output with no transcoding or set it up
depending on your needs.
Personally I want transcoding to the system locale when
stdout/stderr is a terminal and UTF-8 for everything else
(i.e. pipes and files). That would be my defaults.

-- 
Marco

On 10/5/2014 9:18 AM, Andrei Alexandrescu wrote:
> Exceptions are all about centralized error handling. How, and how often, would
> you handle FileNotFoundException differently than PermissionDeniedException?

You would handle it differently if there was extra data attached to that particular exception, specific to that sort of error.

05-Oct-2014 20:18, Andrei Alexandrescu пишет:
> 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?
>

Seems like it should be possible to define multiple interfaces for exceptions, and then catch by that (and/or combinations of such).

Each of interface would be interested in a particular property of exception. Then catching by:

FileException with PermissionException

would mean OS-level permission viloated and it was during file access,

while

ProcessException with PermissionException would mean process manipulation was forbiden, etc.

Of course, some code may be interested only in PermissionException side of things, while other code may want to contain anything related to files, and the catch-all-sensible-ones inside of the main function.

-- 
Dmitry Olshansky

On Sunday, 5 October 2014 at 20:41:44 UTC, Walter Bright wrote:
> On 10/5/2014 8:35 AM, Dicebot wrote:
>> I am fine with non-default being hard but I
>> want it to be still possible within legal language restricions.
>
> D being a systems language, you can without much difficulty do whatever works for you.

Yes but it shouldn't be in undefined behaviour domain. In other words there needs to be a confidence that some new compiler optimization will not break the application completely.

Right now Throwable/Error docs heavily suggest catching it is "shoot yourself in the foot" thing and new compiler release can possibly change its behaviour without notice. I'd like to have a bit more specific documentation about what can and what can't be expected. Experimental observations are that one shouldn't rely on any cleanup code (RAII / scope(exit)) to happen but other than that it is OK to consume Error if execution context for it (fiber in our case) gets terminated. As D1 compiler does not change it is good enough observation for practical means. But for D2 it would be nice to have some official clarification.

I think this is the only important concern I have as long as power user stuff remains possible without re-implementing whole exception system from scratch.