March 19, 2009
On Thu, 19 Mar 2009 19:39:52 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Ary Borenszweig wrote:
>> Andrei Alexandrescu wrote:
>>> Steve Teale wrote:
>>>> Daniel Keep Wrote:
>>>>
>>>>>
>>>>> Steve Teale wrote:
>>>>>> Daniel Keep Wrote:
>>>>>>
>>>>>>> Steve Teale wrote:
>>>>>>>> ...
>>>>>>>>
>>>>>>>> What is the point of class Throwable if you can throw any old class object?
>>>>>>> What class Throwable?
>>>>>> dmd\src\druntime\src\compiler\dmd\object_.d
>>>>>>
>>>>>>>   -- Daniel
>>>>> Ah.
>>>>>
>>>>> Well, if I had to guess, I'd say it was because Throwable objects are
>>>>> more useful than random objects of other types.  Object doesn't give you
>>>>> msg, file, line, info or next.
>>>>>
>>>>>   -- Daniel
>>>>
>>>> But doesn't it rather imply that if you want to be able to throw a class, then it should be derived from Throwable?
>>>
>>> Yes, a check should be added to that effect. Later on we need to actually exploit that only certain types can be thrown in implementing exception chaining.
>>>
>>> What is exception chaining? Consider:
>>>
>>> void weird()
>>> {
>>>     scope(failure) throw new Exception1("hum");
>>>     throw new Exception2("ho");
>>> }
>>>
>>> The C++ model terminates the app when an exception is thrown while the stack is unwound. Java (I was told without having checked) makes the latest exception thrown the "main" exception, and you get to also access the other exceptions by using primitives in class Exception. Is that true?
>>  You can't throw multiple exceptions in Java. What you can do is:
>>  try {
>>   ...
>> } catch(SomeException e) {
>>   throw new AnotherException(e);
>> }
>>  and then AnotherException is thrown with "e" being it's inner exception, and you can check that.
>>
>>>
>>> Anyhow, we should implement a model in D that allows such multiple throws.
>>  What for?
>
> For allowing destructors to throw.
>
> Andrei

Are you sure this is sound?
March 19, 2009
Sean Kelly Wrote:

> Steve Teale wrote:
> > 
> > What is the point of class Throwable if you can throw any old class object?
> 
> I think a case could be made for allowing only children of Throwable to be thrown.  It's possible to throw integers and strings in C++, for example, which is totally ridiculous.  However, at the moment Throwable simply serves as the common base class for Exception and Error, and holds file and line info as well as the stack trace hooks.

It's exactly what you would expect based on the languages that D has borrowed from, but if it does not mean throwable, what's the point?

I still don't know what the significance of Exception and Error might be.

March 19, 2009
Denis Koroskin wrote:
> On Thu, 19 Mar 2009 19:39:52 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Ary Borenszweig wrote:
>>> Andrei Alexandrescu wrote:
>>>> Anyhow, we should implement a model in D that allows such multiple throws.
>>>  What for?
>>
>> For allowing destructors to throw.
>>
>> Andrei
> 
> Are you sure this is sound?

Yes. The notion that throwing destructors should terminate the application pronto is a prejudice we got from C++.

Andrei
March 19, 2009
Andrei Alexandrescu wrote:
> Denis Koroskin wrote:
>> On Thu, 19 Mar 2009 19:39:52 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Ary Borenszweig wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> Anyhow, we should implement a model in D that allows such multiple throws.
>>>>  What for?
>>>
>>> For allowing destructors to throw.
>>>
>>> Andrei
>>
>> Are you sure this is sound?
> 
> Yes. The notion that throwing destructors should terminate the application pronto is a prejudice we got from C++.
> 
> Andrei

And it causes lots of problems, in my experience. Since it usually doesn't terminate the app, just the thread with the defective destructor. Which is unnecessarily difficult to debug.
March 19, 2009
== Quote from Don (nospam@nospam.com)'s article
> Andrei Alexandrescu wrote:
> > Denis Koroskin wrote:
> >> On Thu, 19 Mar 2009 19:39:52 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> >>
> >>> Ary Borenszweig wrote:
> >>>> Andrei Alexandrescu wrote:
> >>>>> Anyhow, we should implement a model in D that allows such multiple throws.
> >>>>  What for?
> >>>
> >>> For allowing destructors to throw.
> >>>
> >>> Andrei
> >>
> >> Are you sure this is sound?
> >
> > Yes. The notion that throwing destructors should terminate the application pronto is a prejudice we got from C++.
> >
> > Andrei
> And it causes lots of problems, in my experience. Since it usually doesn't terminate the app, just the thread with the defective destructor. Which is unnecessarily difficult to debug.

I've considered letting the user supply a custom "unhandled exception" handler for threads.  It just seemed messy given that calling join() on a thread now will rethrow the unhandled exception if there was one.  I figured that the user would join threads he cared about, and if one he didn't care about terminated unexpectedly the perhaps that's not a problem.
March 19, 2009
Thu, 19 Mar 2009 20:44:51 +0000 (UTC), Sean Kelly wrote:

> == Quote from Don (nospam@nospam.com)'s article
>> Andrei Alexandrescu wrote:
>>> Denis Koroskin wrote:
>>>> On Thu, 19 Mar 2009 19:39:52 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>>
>>>>> Ary Borenszweig wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> Anyhow, we should implement a model in D that allows such multiple throws.
>>>>>>  What for?
>>>>>
>>>>> For allowing destructors to throw.
>>>>>
>>>>> Andrei
>>>>
>>>> Are you sure this is sound?
>>>
>>> Yes. The notion that throwing destructors should terminate the application pronto is a prejudice we got from C++.
>>>
>>> Andrei
>> And it causes lots of problems, in my experience. Since it usually doesn't terminate the app, just the thread with the defective destructor. Which is unnecessarily difficult to debug.
> 
> I've considered letting the user supply a custom "unhandled exception" handler for threads.  It just seemed messy given that calling join() on a thread now will rethrow the unhandled exception if there was one.  I figured that the user would join threads he cared about, and if one he didn't care about terminated unexpectedly the perhaps that's not a problem.

The problem is when you have a worker thread which never terminates and sends notifications to the main thread.  Like game logic thread versus main GUI thread.  If logic thread throws, your game suddenly stops working for no apparent reason.
March 19, 2009
== Quote from Sergey Gromov (snake.scaly@gmail.com)'s article
> Thu, 19 Mar 2009 20:44:51 +0000 (UTC), Sean Kelly wrote:
> >
> > I've considered letting the user supply a custom "unhandled exception" handler for threads.  It just seemed messy given that calling join() on a thread now will rethrow the unhandled exception if there was one.  I figured that the user would join threads he cared about, and if one he didn't care about terminated unexpectedly the perhaps that's not a problem.
> The problem is when you have a worker thread which never terminates and sends notifications to the main thread.  Like game logic thread versus main GUI thread.  If logic thread throws, your game suddenly stops working for no apparent reason.

So wrap your logic in a try/catch:

void worker() {
    try {
        doStuff();
    } catch( Throwable t ) {
        notifyProgramOfFailure( t );
    }
}

auto t = new Thread( &worker );

I think a case could be made for simply terminating the
app on an unhandled exception in a thread, but logic
errors are the programmer's responsibility.
1 2
Next ›   Last »