On 15 mar 2012, at 23:57, Jonathan M Davis wrote:

> On Thursday, March 15, 2012 15:25:32 Walter Bright wrote:
>> 
>> If you want to recover, use an Exception.
> 
> In general, I agree. It's just that there are a few cases where it makes sense. The main one has to do with unit tests. In some cases, it makes sense to catch an AssertError within a unit test, because assert is what's used in unit tests. For instance, some programmers want to test their in contracts. The biggest case though is that some programmers want to build more extensive unit testing frameworks on top of the built-in one. And to do that, you have to catch AssertErrors. Personally, I see no need for such frameworks, but some people (e.g. Jacob Carlborg) definitely want them, and if AssertErrors skip scope statements, finally blocks, or destructors, that's going to cause major problems for their frameworks.

I see three ways to solve this:

* Make it safe to catch errors
* Make assert throw an exception
* Make the onAssertError callback usable

Is it possible we can agree on something here or would I need to have my own "assert" function.

-- 
/Jacob Carlborg

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 17 March 2012 16:00, Jacob Carlborg <doob@me.com> wrote:
>
> On 15 mar 2012, at 23:57, Jonathan M Davis wrote:
>
>> On Thursday, March 15, 2012 15:25:32 Walter Bright wrote:
>>>
>>> If you want to recover, use an Exception.
>>
>> In general, I agree. It's just that there are a few cases where it makes sense. The main one has to do with unit tests. In some cases, it makes sense to catch an AssertError within a unit test, because assert is what's used in unit tests. For instance, some programmers want to test their in contracts. The biggest case though is that some programmers want to build more extensive unit testing frameworks on top of the built-in one. And to do that, you have to catch AssertErrors. Personally, I see no need for such frameworks, but some people (e.g. Jacob Carlborg) definitely want them, and if AssertErrors skip scope statements, finally blocks, or destructors, that's going to cause major problems for their frameworks.
>
> I see three ways to solve this:
>
> * Make it safe to catch errors
> * Make assert throw an exception
> * Make the onAssertError callback usable
>
> Is it possible we can agree on something here or would I need to have my own "assert" function.

If something is derived from Throwable, it should be catchable.
The whole point of using the exception mechanism is so that the stack
should be unwound. If you are not going to unwind the stack, don't
make it an exception -- make it a fatal error.

As I said in a previous post, it is possible to add a bool to Error
which indicates if it is guaranteed to be safe, or without guarantee.
And I think that what's you'd hope for an systems programming
language.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 3/17/12 5:37 AM, Leandro Lucarella wrote:
> Well, you know that avoiding the GC in D is not particularly easy, as
> there are so many hidden allocations...

I wonder how we can improve on this. It's becoming quite clear that the GC is a concern of many potential D users.

Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 17 mar 2012, at 17:48, Andrei Alexandrescu wrote:

> On 3/17/12 5:37 AM, Leandro Lucarella wrote:
>> Well, you know that avoiding the GC in D is not particularly easy, as there are so many hidden allocations...
> 
> I wonder how we can improve on this. It's becoming quite clear that the GC is a concern of many potential D users.


To start with: a switch which makes it can error to use any feature the relies on the GC.

-- 
/Jacob Carlborg

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

What about calling onAssertError *after* the assert error is caught in the runtime (outside main)?  That gives you a way to handle unit test failures by e.g. logging them somewhere.  At least it's better than nothing.


-Steve




>________________________________
> From: Sean Kelly <sean@invisibleduck.org>
>To: Discuss the internals of DMD <dmd-internals@puremagic.com>
>Sent: Monday, March 12, 2012 5:29 PM
>Subject: Re: [dmd-internals] Throwing Errors
> 
>On Mar 12, 2012, at 1:13 PM, Jacob Carlborg wrote:
>
>> On 12 mar 2012, at 21:06, Alex wrote:
>> 
>>> It would be hard to write a framework around D unit tests, for instance, where you need to catch AssertErrors if things weren't cleaned up properly (or if it just called abort()). That's just the first thing that comes to mind.
>> 
>> I completely agree. That's what I've been discussion in the "learn" newsgroup. I had a look through the source code of druntime and found "onAssertError". I don't know if it's used or not but sounds exactly like the function I need. But unfortunately the function to set the assert handler is deprecated.
>> 
>> http://dlang.org/phobos/core_exception.html#onAssertError http://dlang.org/phobos/core_exception.html#setAssertHandler
>
>The handler is deprecated because DMD doesn't generate a valid call stack for _d_assert (which calls onAssertError) so it's impossible to return from the assert handler without throwing.  This rendered the assert handler largely useless and after a few years of no one using it I decided to deprecate it.  I'd be happy to keep the assert handler if people actually want it though, or if DMD changes its codegen.  Personally, I'd like to be able to assert without throwing in some testing situations, and overriding a handler seems like an appropriate way to do this.
>_______________________________________________
>dmd-internals mailing list
>dmd-internals@puremagic.com
>http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>
>

On 03/17/12 17:55, Jacob Carlborg wrote:
> 
> On 17 mar 2012, at 17:48, Andrei Alexandrescu wrote:
> 
>> On 3/17/12 5:37 AM, Leandro Lucarella wrote:
>>> Well, you know that avoiding the GC in D is not particularly easy, as there are so many hidden allocations...
>>
>> I wonder how we can improve on this. It's becoming quite clear that the GC is a concern of many potential D users.
> 
> 
> To start with: a switch which makes it can error to use any feature the relies on the GC.

A compiler switch wouldn't be enough, even if it was possible. A user may want
to avoid (implicit) GC allocations in only certain code paths. Some kind of attribute
annotation scheme could help (pure-like); otherwise one would have to either duplicate
a lot of code and/or split the RT/non-rt parts of the app into different processes.
IOW, the situation wouldn't change much.

artur
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals