On Monday, 3 April 2017 at 21:31:39 UTC, Jonathan M Davis wrote:
> though the exception message poses a similar problem (especially if you'd normally construct it with format), and I don't know how you get around that other than not using anything more informative than string literals

This is why strings are considered harmful to me. Instead, you can make a new exception class inline that stores the data and lazily sinks it to the toString delegate on demand. This doesn't work for all data types, but it does for a lot of useful ones.

It is also another reason why this proposal is not that great - having a helper function allocate the exception means you can avoid allocating the string.

This file shows like 3 concepts I have with exceptions, but the RaisedExceptionDetails.toString shows this:

http://arsdnet.net/exception.d


It is an easily solved library problem... and would be *easier* to use than format().

On 4/3/2017 2:31 PM, Jonathan M Davis via Digitalmars-d wrote:
> Yeah, the simple fact that you can't allocate exceptions in @nogc code is
> crippling to @nogc, and a lot of code that could otherwise be @nogc can't be
> because of exceptions - though the exception message poses a similar problem
> (especially if you'd normally construct it with format), and I don't know
> how you get around that other than not using anything more informative than
> string literals. Unless I missed something, this proposal seems to ignore
> that particular issue.


You're right that this proposal does not address how memory is allocated for anything indirectly referenced by the exception object. That is an independent issue, and is not peculiar to exception objects.

On 4/3/2017 2:38 PM, David Nadlinger wrote:
> On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
>> The idea of this proposal is to make a nogc program much more achievable.
>> Currently, in order to not link with the GC, you can't use exceptions (or at
>> least not in a memory safe manner). A solution without memory safety is not
>> acceptable.
>
> You could use an exception instance allocated in TLS (which is, in fact, what
> Weka does in large parts of the code). This should be perfectly memory safe,
> although there are of course implications for exception chaining. (By default,
> you'll still get an allocation for the associated TraceInfo, but you can disable
> that.)
>
> Of course, this is not to say that a nicer/more general solution wouldn't be
> appreciated.
>
>  — David

Using a singleton in TLS is indeed memory safe, as long as you don't do things like keep a reference to it around and expect it not to change.

On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
> I don't see a point to having disparate allocation strategies for exception objects.

Example: company wants to use their custom GC (like sociomantic) with Phobos. They want to do this even for exceptions because they believe that things will be faster if they're able to completely control when any memory is freed. Your solution does not help these people use Phobos because the compiler will be inserting calls to free in places they don't want, which will slow down their program.

Solution:

1. allocate exceptions in Phobos with theAllocator
2. if theAllocator is still the default of the GC, then the user doesn't have to do anything else because the exception will be garbage collected. No code is broken (I think) for everyone who doesn't set theAllocator.
3. If theAllocator is different, then the onus is on the user to properly free the exception

In my mind, the whole point of std.allocator was to make Phobos allocation strategy agnostic. So, at some point, we're going to have to find a way to integrate std.allocator into Phobos to get rid of the GC usage anyway. Exceptions seem like as good as any other place to start.

Or, find a way to get RC with objects.

> In any case, the compiler will insert calls to specific functions to allocate/free exception objects. Those functions will be in druntime, but anyone can override them with their own implementation.

And this will be done by changing the meaning of people's code and adding a special case to new.

This smells like C++.

On Monday, 3 April 2017 at 22:20:23 UTC, Walter Bright wrote:
> You're right that this proposal does not address how memory is allocated for anything indirectly referenced by the exception object. That is an independent issue, and is not peculiar to exception objects.

There is no issue specific to Exception here.

On Monday, 3 April 2017 at 23:33:10 UTC, Jack Stouffer wrote:
> On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
>> I don't see a point to having disparate allocation strategies for exception objects.
>
> Example: company wants to use their custom GC (like sociomantic) with Phobos. They want to do this even for exceptions because they believe that things will be faster if they're able to completely control when any memory is freed.

AFAIK if an exception is going to be triggered, you've already entered the horribly slow path of stack unwinding that should never occur in the normal operation of any program that cares about performance. I doubt the performance of the exceptions' memory management will register compared to that.

> Your solution does not help these people use Phobos because the compiler will be inserting calls to free in places they don't want, which will slow down their program.

If their program slows noticeably from any changes to the slow path I'm forced to ask why it spends so much time on the slow path; this sounds like there is something fundamentally wrong with the program.

>
> Solution:
>
> 1. allocate exceptions in Phobos with theAllocator
> 2. if theAllocator is still the default of the GC, then the user doesn't have to do anything else because the exception will be garbage collected. No code is broken (I think) for everyone who doesn't set theAllocator.
> 3. If theAllocator is different, then the onus is on the user to properly free the exception

Consider the following:
- Application sets theAllocator to something different
- Application calls into (non-Phobos) library
- (non-Phobos) library calls into Phobos
- Phobos throws an exception (allocated using theAllocator)
- (non-Phobos) library knows how to handle the exception semantically and thus catches it
- To properly free the exception the (non-Phobos) library author must defensively call theAllocator.dispose.

AFAICT this solution will end up with everyone always calling theAllocator.dispose when catching from Phobos.

Am Mon, 03 Apr 2017 14:31:39 -0700
schrieb Jonathan M Davis via Digitalmars-d
<digitalmars-d@puremagic.com>:

> On Monday, April 03, 2017 14:00:53 Walter Bright via Digitalmars-d wrote:
> > The idea of this proposal is to make a nogc program much more achievable. Currently, in order to not link with the GC, you can't use exceptions (or at least not in a memory safe manner). A solution without memory safety is not acceptable.
> 
> Yeah, the simple fact that you can't allocate exceptions in @nogc code is crippling to @nogc, and a lot of code that could otherwise be @nogc can't be because of exceptions - though the exception message poses a similar problem (especially if you'd normally construct it with format), and I don't know how you get around that other than not using anything more informative than string literals. Unless I missed something, this proposal seems to ignore that particular issue.
> 
> - Jonathan M Davis
> 

Allocate the string using an Allocator, free in the Exceptions ~this?

This has to be integrated somehow with the copying scheme though, so you'll probably need some kind of reference counting for classes again or duplicate the string on every copy.

-- Johannes

On Monday, April 03, 2017 15:20:23 Walter Bright via Digitalmars-d wrote:
> On 4/3/2017 2:31 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Yeah, the simple fact that you can't allocate exceptions in @nogc code
> > is
> > crippling to @nogc, and a lot of code that could otherwise be @nogc
> > can't be because of exceptions - though the exception message poses a
> > similar problem (especially if you'd normally construct it with
> > format), and I don't know how you get around that other than not using
> > anything more informative than string literals. Unless I missed
> > something, this proposal seems to ignore that particular issue.
>
> You're right that this proposal does not address how memory is allocated for anything indirectly referenced by the exception object. That is an independent issue, and is not peculiar to exception objects.

No, it's not a problem that's specific to exceptions, but the string for an exception message is pretty critical and is going to have a significant impact on the ability to use @nogc with exceptions. Just being able to have the exception itself be allocated and managed safely via @nogc is definitely a step up, but if we don't have a reasonable way to manage the exception's message in @nogc code, then in many cases, we have a serious problem with how informative exceptions are. And if you really don't care about the exception message saying anything more than you can put in a string literal, you can always pre-allocate the excetion and avoid the whole @nogc problem that way without any of the proposed language changes. As such, I'm inclined to think that the benefits of the proposed changes are minimal if they don't fix the problem with the exception's message being GC-allocated.

- Jonathan M Davis

On Sunday, 2 April 2017 at 20:35:27 UTC, Walter Bright wrote:
> On 4/2/2017 8:24 AM, Dmitry Olshansky wrote:
>> [...]
>
> That's right.
>
>
>> [...]
>
> Yes, it's possible. But I'd have to be convinced that there isn't some other problem with a design that requires preallocated exceptions.
>
> [...]

I think the point here is that some people already use pre-allocated exceptions. With this proposal, they'd have to change their codebase or suddenly have it go much slower.

Atila

On 4/4/2017 1:08 AM, Atila Neves wrote:
> I think the point here is that some people already use pre-allocated exceptions.
> With this proposal, they'd have to change their codebase or suddenly have it go
> much slower.

High performance code should never have exceptions in the fast path. The code gen is heavily and unapologetically biased towards speed in the non-exception path. This is true for C++ and D.