February 21, 2012
On 2/20/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> Actually, even that isn't ideal. How is the translator to know what on earth {0} and {1} are?

Sorry, I didn't mean this in the concept of exceptions but generally when calling writefln & format. This exceptions thread has exploded so fast I haven't kept up with the discussions. :P
February 21, 2012
Am 21.02.2012 09:15, schrieb H. S. Teoh:
> Sorry for this super-long post

perfect length, helps to clean the brain and focus on the real problems again
February 21, 2012
On 2012-02-21 01:51, H. S. Teoh wrote:
> On Mon, Feb 20, 2012 at 06:19:32PM -0600, Andrei Alexandrescu wrote:
>> On 2/20/12 5:46 PM, Nick Sabalausky wrote:
> [...]
>>> You've suggested adding "Variant[string] info" to Exception for the
>>> sake of i18n. I think that's what he's referring to. You *could*
>>> argue that's not technically i18n, but so far i18n seems to be the
>>> only real use-case for it (although even that much has been disputed
>>> in light of reflection).
>>
>> All formatting and rendering of the exception information is helped.
>> And I think that's great because that's the most common activity one
>> would do with exceptions.
> [...]
>
> Then, obviously, different development environments are leading to
> vastly different conclusions, because I can't for the life of me imagine
> that the most common activity you would do with an exception is to print
> it.  That may be true for a certain class of applications, say
> command-line tools like compilers and stuff. But that's absolutely not
> the case at my work project. There, exceptions are usually handled by
> code and almost never output anywhere, and even when they are, for the
> most part they just print a simple string literal right from the source
> code into a debug log channel. Only a tiny percentage of exceptions
> actually make it all the way to being formatted into a nice localized
> string displayed to the user.
>
> For the more common case of printing to the debug log, the current
> Exception facilities (string msg) are more than good enough (since the
> intended audience is the developers themselves). The i18n stuff is
> handled by catching the relevant exception by type and looking up the
> localized string at the catcher level. Any additional info inside the
> exception object itself isn't used for formatting the localized string
> anyway, since the user has no idea what it all means.
>
>
> T
>

I completely agree.

-- 
/Jacob Carlborg
February 21, 2012
Le 20/02/2012 21:57, Andrei Alexandrescu a écrit :
> On 2/20/12 1:45 PM, Jonathan M Davis wrote:
>> On Monday, February 20, 2012 20:42:28 deadalnix wrote:
>>> Le 20/02/2012 20:27, Jonathan M Davis a écrit :
>>>> On Monday, February 20, 2012 11:15:08 H. S. Teoh wrote:
>>>>> That's why I proposed to use runtime reflection to scan the exception
>>>>> object for applicable fields. Then you get the best of both worlds:
>>>>> the
>>>>> message formatter doesn't need to know what the fields are, and you
>>>>> get
>>>>> full compile-time type checking for catching code that directly
>>>>> accesses
>>>>> the fields.
>>>>
>>>> That would certainly be better.
>>>>
>>>> - Jonathan M Davis
>>>
>>> This is way better than Variant[string], but unimplemented ATM.
>>
>> Yes, but you can use compile-time constructs to generate it. And as you
>> pointed out in another post, tupleof should do the trick. Regardless, the
>> point is that using reflection of some kind is a much better solution
>> than
>> using variant.
>
> Agreed. Ideally adding a sort of mixin to any class would enable it for
> advanced run-time information:
>
> class DRoxException : Exception
> {
> mixin(enableRTTI);
> ... normal implementation ...
> }
>
>
> Andrei
>
>

Why not using std.rtti and generate run time reflection info from compile time reflexion capability ?

This would enable that feature without writing it the language, so it would prevent to bloat the binary when size matter and reflexion isn't needed.
February 21, 2012
On Saturday, 18 February 2012 at 18:52:05 UTC, Andrei Alexandrescu wrote:
> From experience I humbly submit that catching by type is most of the time useless.

Completely disagree. Types allow to control place for "catch". Say, some deeply nested function catches its own exceptions, while outer function catches the rest - exceptions higher in hierarchy. But to have benefit you have to create exceptions hierarchy - this is the main point.
February 21, 2012
On Tuesday, 21 February 2012 at 02:23:58 UTC, Andrei Alexandrescu wrote:
> On 2/20/12 7:02 PM, Juan Manuel Cabo wrote:
>> oops, sorry!! I just saw a post by someone named Jose. My thousand apollogies!!
>
> I got confused. It was your argument I meant to refer to - adding info to the exception in flight.
>
> Andrei

I'd implement this along these lines:

class WithErrorCode(E) : E {
  int errorCode;
  this(Args)(int err, Args args) { this.errorCode = err; super(args); }
}

and add this wrapper where relevant. e.g. replace:
throw new FileNotFoundException(...);
with something like:
throw new WithErrorCode!FileNotFoundException(-1, ...);

This is a localized change that doesn't affect all uses of exceptions and it remains type-safe. surely this is a better solution than the hash table?
February 21, 2012
First great post. Don't be sorry, it is insightful. The Condition catgory make a lot of sense to me.

Le 21/02/2012 09:15, H. S. Teoh a écrit :
> Currently, I'm still unsure whether Conditions and Exceptions should be
> unified, or they should be kept separate; deadalnix recommended they be
> kept separate, but I'd like to open it for discussion.
>

I think we could reconciliate the 2 worlds. Condition may provide @property Exception exception() so you can get the Exception. Eventually, the Condition can return itself so it is the Exception.

This Exception can be used by the handler to get information about the problem more specifically (if required). The Exception can also be used to throw it, if no handler is provided, or if the handler decide it is the right thing to do.

I suggested this mecanism should be implemented into std.condition and still think this is the way to go. Addition to the language itself should be as limited as possible (ie only occur if the compiler can take advantage of this, for example to optimize, or if this isn't implementable using the current state of the language).

This mecanism is not intended to replace Exception, but to provide a more convenient, higher level (and probably more performant) than the Exception mecanism. We fail back to Exceptions if this mecanism fail.
February 21, 2012
Le 21/02/2012 11:40, Vincent a écrit :
> On Saturday, 18 February 2012 at 18:52:05 UTC, Andrei Alexandrescu wrote:
>> From experience I humbly submit that catching by type is most of the
>> time useless.
>
> Completely disagree. Types allow to control place for "catch". Say, some
> deeply nested function catches its own exceptions, while outer function
> catches the rest - exceptions higher in hierarchy. But to have benefit
> you have to create exceptions hierarchy - this is the main point.

Well, we must consider that the only thing we have to select Exception if the type. But do we really want to catch on type, or do we use the type because we lack of a better mecanism select exceptions we want to handle ?

A new type should be added only if it make sense to provide additionnal informatiosn about the issue faced. The pertienent information will depend on the issue, so some issue will require new types of Exception.

Plus, sometime, things doesn't fit in a Tree shape.

But creating Exception just to catch specifically thoses don't make a lot of sense. This is why several person proposed ways to add a way to select more precisely what we want to catch.
February 21, 2012
On 2012-02-21 03:34, Andrei Alexandrescu wrote:
> On 2/20/12 6:51 PM, H. S. Teoh wrote:
>> On Mon, Feb 20, 2012 at 06:19:32PM -0600, Andrei Alexandrescu wrote:
>>> On 2/20/12 5:46 PM, Nick Sabalausky wrote:
>> [...]
>>>> You've suggested adding "Variant[string] info" to Exception for the
>>>> sake of i18n. I think that's what he's referring to. You *could*
>>>> argue that's not technically i18n, but so far i18n seems to be the
>>>> only real use-case for it (although even that much has been disputed
>>>> in light of reflection).
>>>
>>> All formatting and rendering of the exception information is helped.
>>> And I think that's great because that's the most common activity one
>>> would do with exceptions.
>> [...]
>>
>> Then, obviously, different development environments are leading to
>> vastly different conclusions, because I can't for the life of me imagine
>> that the most common activity you would do with an exception is to print
>> it.
>
> Different strokes for different folks I'd say. I think I could claim a
> little authority on diversity. I've worked on an extremely diverse range
> of applications; in fact I've made a point to acquire broad specialization.
>
> In virtually all systems I've worked on, rendering meaningful error
> messages out of exception information has been a major concern, and in
> most of them the problem has been poorly addressed. It is very exciting
> to have an opportunity to improve on the state of affairs.
>
>
> Andrei

I think the correct way of handling this is provide enough information in the exception so a message can be built where the exception is caught. It might happen the you want to catch the same exception in different parts of the code and build different messages.

-- 
/Jacob Carlborg
February 21, 2012
On Sun, 19 Feb 2012 23:04:59 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/19/12 4:00 PM, Nick Sabalausky wrote:

>> Seriously, how is this not *already* crystal-clear? I feel as if every few
>> weeks you're just coming up with deliberately random shit to argue so the
>> rest of us have to waste our time spelling out the obvious in insanely
>> pedantic detail.
>
> It sometimes happened to me to be reach the hypothesis that my interlocutor must be some idiot. Most often I was missing something.

I get the impression that you find "Devil's advocate" a useful tool for generating debate and out of the box thinking.. there is something to be said for that, but it's probably less annoying to some if you're clear about that from the beginning. :p

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/