On Sunday, 19 February 2012 at 00:50:07 UTC, Jonathan M Davis wrote:
> On Saturday, February 18, 2012 16:46:43 H. S. Teoh wrote:
>> I can't believe something this simple has to be explained so
>> elaborately. I thought all of us here knew how to use OO??
>
> I think that the problem stems from people frequently using exceptions incorrectly, and many of the C++ programmers probably haven't _ever_ seen them used correctly, since I don't think that it's very common for C++ programs to define exception hierarchies - especially not advanced ones like Java has. And when you see a lot of bad exception code, that tends to turn you off to them, and it definitely doesn't show you how to use them correctly.
>
> - Jonathan M Davis

Problem is, "no one" using exception handling correctly including language experts. There is no consensus on where they are useful or not. Neither articles nor codes help you. Go read every single one of them and come back and code something. I invested a lot of time on it, yet i am now using it when i need an aggressive assert.

It is a great idea but incomplete.

On 2/19/12 7:37 AM, Timon Gehr wrote:
> On 02/18/2012 07:52 PM, Andrei Alexandrescu wrote:
>> There's a discussion that started in a pull request:
>>
>> https://github.com/alexrp/phobos/commit/4b87dcf39efeb4ddafe8fe99a0ef9a529c0dcaca
>>
>>
>>
>> Let's come up with a good doctrine for exception defining and handling
>> in Phobos. From experience I humbly submit that catching by type is most
>> of the time useless.
>>
>>
>> Andrei
>
> Would giving std.concurrency.OwnerTerminated and
> std.concurrency.LinkTerminated a common supertype make sense?

I am not sure.

Andrei

On 2/19/12 4:30 AM, Juan Manuel Cabo wrote:
> Hello D community! This is my first post!! I hope I can bring clarity to
> all this. If not, I apologize.
[snip]

Thanks for an insightful post. If you found the time, it would be great if you could translate your paper on exceptions from Spanish.

Andrei

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jhr0vq$24t0$1@digitalmars.com...
> On 2/19/12 5:22 AM, deadalnix wrote:
>> Le 19/02/2012 08:05, Andrei Alexandrescu a écrit :
>>> How about a system in which you can say whether an exception is I/O related, network related, recoverable or not, should be displayed to the user or not, etc. Such is difficult to represent with inheritance alone.
>>>
>>
>> That may sound great on the paper, but it isn't. The fact that an exception is recoverable or not depend often on your program and not on the cause of the exception.
>
> This is self-evident. Again, the meaning of "recoverable" is "operation may succeed if retried with the same input". It's a hint for the catch code. Of course the program is free to ignore that aspect, retry a number of times, log, display user feedback, and so on. But as far as definition goes the notion is cut and dried.
>

WTF? "Recoverable" means "can be recovered from". Period. The term doesn't have a damn thing to do with "how", even in the context of exceptions. It *never* has. If you meant it as "operation may succeed if retried with the same input", then fine, but don't pretend that *your* arbitrary definition is "cut and dried".

On 2/19/12 3:26 AM, Jonathan M Davis wrote:
> On Sunday, February 19, 2012 19:00:20 Daniel Murphy wrote:
>> I wasn't really serious about implicit fallthrough.
>
> Lately, it seems like I can never tell whether anyone's being serious or not
> online. :)
>
>> Out of the syntaxes I could come up with:
>> catch(Ex1, Ex2 e)
>> catch(e : Ex1, Ex2)
>> catch(Ex1 | Ex2 e) // java 7 syntax, horrible
>>
>> I like (e : list) the best.  Naturally it would also accept a type tuple of
>> exceptions.
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=7540
>
> LOL. Personally, I actually think that the Java 7 syntax looks great (I'd
> never seen it before), but catch(e : Ex1, Ex2) is just as good and more
> consistent with the language as a whole, since it doesn't try to give any
> operators a new meaning (as Java's does).
>
> - Jonathan M Davis

The Java7 syntax looks meaningful to me, too - you want to catch the union type. A possibility that wouldn't change the language for us would be to catch Algebraic!(Ex1, Ex2).

Andrei

On 2/19/12 3:17 AM, Jonathan M Davis wrote:
> "As much information as possible" is way more than a transient property. If my
> code is going to retry or do something else or give up, it needs enough
> information to know what went wrong, not just whether the function which was
> called think it might work on a second try.
>
> Having an exception hierarchy provides some of that information simply with
> the types, and makes it easier to organize code based on what went wrong (e.g.
> separate catch blocks for each type of exception). And having that hierarchy
> also means that the derived types can have additional information beyond their
> type which could be useful but is specific to that problem and so wouldn't make
> sense on a general exception type.
>
> I really don't see what transient buys you in comparison to that.

A notion of transiency planted fundamentally in all exceptions allows one to act on it regardless of origin and hierarchy.

Andrei

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jhr67g$2dup$4@digitalmars.com...
>
> The Java7 syntax looks meaningful to me, too - you want to catch the union type. A possibility that wouldn't change the language for us would be to catch Algebraic!(Ex1, Ex2).
>
> Andrei

That would still require changing the language, just not the syntax.

(E : A, B) was just the syntax for listing base classes.

On 2/19/12 3:15 AM, H. S. Teoh wrote:
> I don't understand.  So instead of providing enough information to the
> caller about the nature of the problem, you're essentially handing them
> an anonymous note saying "A generic problem occurred, which _may_ go
> away if you retry. I have no further information for you. Do you want to
> retry?"?
>
> But without further information, how *can* you even make that decision?
> Without any way of determining what caused the error or even what it is,
> how could you know whether it makes sense to retry it?
>
> Or is that transient flag intended to mean that it *should* be retried
> since it "might" succeed the next time round? How should the caller
> decide whether or not to go ahead with the retry? Flip a coin? Always
> retry?  Always fail? I can't imagine any sane application where code
> would say "if this operation fails with a transient error, always fail"
> where any arbitrary set of exceptions might potentially be transient?
> What's a "transient error" anyway, from the application's POV anyway?
> What's a "transient error" from a database app's POV? A 3D shooter? A
> text editor? Is it even possible to have a consistent definition of
> "transient" that is meaningful across all applications?

I mentioned the definition a couple of times. Transient means retrying the operation with the same state may succeed. It is a property of the exception regardless of context. Of course, caller code may ignore it or use additional information.

Even network errors may be of both kinds. A network timeout error is transient. A DNS lookup error or malformed URL are not.

> It seems to me that if an error is "transient", then the called function
> might as well just always retry it in the first place, instead of
> throwing an exception.

Client code must decide on the appropriate action, including UI cues, a configurable number of retries, logging, and such.

> Such an exception is completely meaningless to
> the caller without further information. Yet it seems that you are
> suggesting that it's more meaningful than FileNotFoundException?

This is a misunderstanding. Transiency is a cross-cutting property. A FileNotFoundException is great (and non-transient btw).


Andrei

On 2/19/12 2:49 AM, H. S. Teoh wrote:
[snip]
> To me, this is a giant hint that OOP is a good solution. You want a
> class hierarchy rooted at Exception. And groups of related exceptions
> probably should be rooted under their respective base classes under
> Exception.
>
> If you have a better way to solve this, I'm waiting to hear it.

I don't. This thread is predicated on the assumption that the current approaches to exception handling are wanting, so it's time to look outside the box. It's also reasonable to assume that people involved in this thread do have an understanding of current mechanisms, so rehashes thereof are unnecessary.

Andrei

On 2/19/12 2:21 AM, H. S. Teoh wrote:
> Getopt isn't really the best use case for elaborate exception
> hierarchies. Perhaps we should use file I/O or network/socket I/O
> instead.

This is exactly what we should avoid: regressing to well-trodden ground. We shouldn't discuss OOP only in terms of Animal and Mammal, and we shouldn't discuss exceptions only in terms of IOException and NetworkException. We should look at the "uncomfortable" cases.


Andrei