On 2/7/2014 12:14 PM, Dmitry Olshansky wrote:
> Fast, simple and according to the standard. Best of all - no stinkin'
> exceptions! ;)

Nice find. Looks good to me.

On 2/7/2014 12:51 PM, Dmitry Olshansky wrote:
> It's deh.d or rather deh_win32./ deh_win64_posix.d and it doesn't look like
> _all_ that lot especially if you have no finally blocks and the only catch is
> the top-most catch-all.

It's a heluva lot slower than "jmp".

09-Feb-2014 02:16, Walter Bright пишет:
> On 2/7/2014 12:14 PM, Dmitry Olshansky wrote:
>> Fast, simple and according to the standard. Best of all - no stinkin'
>> exceptions! ;)
>
> Nice find. Looks good to me.

https://d.puremagic.com/issues/show_bug.cgi?id=12113

-- 
Dmitry Olshansky

On Saturday, 8 February 2014 at 22:11:13 UTC, Dmitry Olshansky wrote:
> Again I'm trying to say that framing stack unwinding as the culprit of vibe.d crawling under bad requests is plain wrong, and that was the focal point of the original argument.

Can you see if it is better with this little patch?

https://github.com/D-Programming-Language/druntime/pull/717

on a simple test, I got a 20x speedup on most exceptions by lazy generating the stack trace upon request in toString (though if you are printing it anyway you won't see a difference)

On Saturday, 8 February 2014 at 22:03:13 UTC, Walter Bright wrote:
> You can make the lookup faster by compromising the function code generation, but this is considered an unacceptable tradeoff.

"Compromising"? You mean they had to modify codegen, which they didn't want to. Clearly, if you know the return address you also could have stack info access close to it (at a fixed offset), at no runtime cost whatsoever.

But the c++ Dwarf way of doing it was developed for Itanium which was targetting HPC, for which you probably don't need exceptions all that often. So it made sense in that context.

For regular applications it makes no sense, and with whole program analysis (or language level linker) you probably often can get a good match at the throw site.

AND (this just has to be said) if D is really meant to be a SAFE programming language then the language should NOT encourage programmers to a coding style where you can fail to test for errors. The obvious solution is to ensure that you cannot ignore errors unless you are explicit about it. Exceptions ensure that.

Having 3 different ways of returning errors is not a good strategy for safe and bug free programming.

Ah, I just had to say it... ;)

On Saturday, February 08, 2014 18:03:54 Meta wrote:
> On Saturday, 8 February 2014 at 11:24:56 UTC, Dmitry Olshansky
> 
> wrote:
> > 08-Feb-2014 03:01, Meta пишет:
> >> On Friday, 7 February 2014 at 22:57:26 UTC, Jonathan M Davis
> >> 
> >> wrote:
> >>> On Friday, February 07, 2014 20:43:38 Dmitry Olshansky wrote:
> >> You could always return an Option!char. Nullable won't work
> >> because it
> >> lets you access the naked underlying value.
> > 
> > This is ridiculously distracting suggestion and simply has no merits whatsoever.
> > 
> > To underline how impractical this suggestion is: currently every code out there expect dchar out of .front not some magic animal called 'Option!char'.
> 
> I'm not actually suggesting a replacement. Just wishful thinking on how the function could've been better designed.

I don't see how returning Nullable!dchar would improve decode function at all. Currently, it throws on invalid UTF, so you don't have to check the return value, and your code can avoid caring about decode errors except for the points where you put your catches (which are generally in far fewer places than the number of places that decode gets called - be it directly or indirectly). On the other hand, with Nullable!dchar, you'd have to always check the result or risking hitting an assertion when you don't check the result (or ending up with dchar.init in -release). I don't see how that's better than the current situation at all. It just makes decode harder to use.

And Dmitry's suggestion is better than both. We end up returning the Unicode character specifically intended to designate bad encodings (\uFFFD) such that you don't even have to care that there was a decode error. You just decode the string and use it. It will just be one more character in the string that doesn't match what you're looking for for find and the like, and pretty much nothing should choke on it. Anything which then cares about Unicode validity can use isValidUnicode (once we have it) to validate the string instead of relying on decode to throw. It will clean up string processing in the face of invalid Unicode quite nicely.

So, I don't see how using Nullable!dchar as you suggest would ever have been a better design.

- Jonathan M Davis

Am Sat, 08 Feb 2014 11:33:51 +0000
schrieb "Jakob Ovrum" <jakobovrum@gmail.com>:

> On Saturday, 8 February 2014 at 11:27:27 UTC, Jonathan M Davis wrote:
> > On Saturday, February 08, 2014 11:17:25 Jakob Ovrum wrote:
> >> On Saturday, 8 February 2014 at 11:05:38 UTC, Dmitry Olshansky wrote:>
> >> 
> >> > If both are thread-local and cached I see no problem
> >> > whatsoever.
> >> > The thing is the current "default" of creating exception is
> >> > AWFUL.
> >> > And D stands for sane defaults and the simple path being good
> >> > last time I checked.
> >> 
> >> How is it not a problem? XException's fields (message, location etc) would be overwritten by the latest throw site, and its `next` field would point to itself.
> >
> > Then we have multiple of them, or we new up another one when a
> > second one is
> > needed. Even if it were only the first exception which avoided
> > the allocation,
> > it would be a big gain, and in most cases, you're only going to
> > get a single
> > exception, or the exceptions will be of different types.
> >
> > - Jonathan M Davis
> 
> Yes, I'm sure there is a cool solution, I'm just pointing out that it's not as simple as statically allocating.
> 
> I think it would be a nice exercise to compose such a solution with std.allocator.

Yes, it doesn't seem feasible otherwise. Since you can call functions recursively you could potentially chain exceptions from the same line of code several times.

  catch (Exception e)
  {
      staticException.line = __LINE__;
      staticException.file = __FILE__;
      staticException.next = e;  // e.next is staticException
      throw staticException;
  }

You'd have to flag staticException as "in use" and spawn a new instance every time you need another one of the same type. Since there is no way to reset that flag automatically when the last user goes out of scope (i.e. ref counting), that's not even an option.

Preallocated exceptions only work if you are confident your exception wont be recursively thrown and thereby chained to itself. Granted, the majority of code, but really too much cognitive load when writing exception handling code.

-- 
Marco

Am Sat, 08 Feb 2014 14:01:12 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 2/7/2014 8:40 AM, Dmitry Olshansky wrote:
> > Meh. If exceptions are such a liability we'd better make them (much) faster.
> 
> They can be made faster by slowing down non-exception code.
> 
> This has been debated at length in the C++ community, and the generally accepted answer is that non-exception code performance is preferred and exception performance is thrown under the bus in order to achieve it.
> 
> I think it's quite a reasonable conclusion.

https://yourlogicalfallacyis.com/black-or-white

The reasons for slow exceptions in D could be the generation of stack trace strings or the garbage collector instead of inherent trade offs to keep the successful code path fast.

And static allocation isn't an exactly appealing option...

  throw staticException ? staticException : (staticException =
  new SomethingException("Don't do this at home kids!"));

and practically out of question when you need to chain exceptions and your call stack could contain this line of code more than once, resulting in infinite loops in exception chains as a new bug type in D, that is fixed by writing:

  catch (Exception e) {
      throw (staticException ? (e.linksTo(staticException) ? staticException.dupThenWrap(e) : staticException) : (staticException = new SomethingException("Don't do this at home kids!"));
  }

-- 
Marco