capture backtrace in throw statement

[Stepan Koltsov]

Hi.

After years of programming in Java I really miss the ability to print backtrace of exception.

I've written a patch that captures backtrace in throw statement:

https://github.com/stepancheg/clay/commit/ed955c130ec6b2ad3e733f102b29438cdd05c5b9

(explanation of what it does is in commit message).

What do you think about this feature? If it is good, I'll fix broken test and send a pull request.

--
Stepa

[Stepan Koltsov]

Hi, again.

Does anybody think anything about this feature:

* should it be implemented some other way?
* does this feature worth inclusion into the compiler?

Meanwhile, I improved the patch:

* tests fixed
* file and line number of throw statement is now captured

See two last patches in branch: https://github.com/stepancheg/clay/commits/bte

--
Stepa

[Joe Groff]

On Sun, Sep 23, 2012 at 10:40 AM, Stepan Koltsov
<stepan....@gmail.com> wrote:
> Hi, again.
>
> Does anybody think anything about this feature:
>
> * should it be implemented some other way?
> * does this feature worth inclusion into the compiler?
>
> Meanwhile, I improved the patch:
>
> * tests fixed
> * file and line number of throw statement is now captured
>
> See two last patches in branch:
> https://github.com/stepancheg/clay/commits/bte

Hi Stepan. Sorry for missing your first message. This is a great idea,
and a reasonable implementation. Performance should not be an issue
because the backtrace only needs to be captured when an exception is
actually thrown, and exceptions shouldn't be thrown on a critical
path. It would be nice not to expose those magic __exc_ identifiers,
though I can't think of a good way to avoid doing so without putting
that data in the exception itself or extending the syntax of catch.
The exceptionAs and exceptionAsAny hooks could be implemented a bit
more cleanly without named returns using a scope guard:

overload exceptionAs(#T, exp:RawPointer) : T, Backtrace, StringLiteralRef, Int {
finally freeRawMemory(exp);
return moveUnsafe(nestedVariantAs(exceptionObject(exp).exception,
T)), moveUnsafe(exceptionObject(exp).backtrace),
exceptionObject(exp).file,
exceptionObject(exp).line;
}

Other than that, it looks good.

-Joe

[Stepan Koltsov]

On Sunday, September 23, 2012 9:59:08 PM UTC+4, Joe Groff wrote:

On Sun, Sep 23, 2012 at 10:40 AM, Stepan Koltsov
<stepan....@gmail.com> wrote:
> Hi, again.
>
> Does anybody think anything about this feature:
>
> * should it be implemented some other way?
> * does this feature worth inclusion into the compiler?
>

> ...

 

...

Other than that, it looks good.

Changed exceptionAs* and pushed to master:

https://github.com/jckarter/clay/commit/0707090773707cf3652917f7dbfea4fc71e5e07c

--
Stepan Koltsov

[Artem Grinblat]

Hi, Stepan.
In Java one can avoid the backtrace cost by keeping the exception object around and throwing it multiple times. Is this applicable to clay (with your patch)?

[Stepan Koltsov]

Hi, Artem.

It is not currently possible.

Currently, throw statement calls `throwValue` function. We could do one of two things:

— add another function `throwValueNoBacktrace`, so developer could call it explicitly if he doesn't need backtrace
— add function:

```
define ExceptionNeedsBacktrace?(e): Bool; // exception is captured if function returns true
overload ExceptionNeedsBacktrace?(e) = true;
```

so developer could overload it for some exception type.

Don't know which way is better.

--
Stepan

[Artem Grinblat]

I find that exceptions are often buried deep inside some library code, yet there are places when you need that backtrace for the exception in order to debug it and there are places which would be best run without the stack trace overhead. That is, the decision to include the backtrace or not include it might make more sense at the catch site. In C++ I'm trying to do this with thread-local controls ( cf. http://code.google.com/p/libglim/source/browse/trunk/exception.hpp for some thoughts ).

воскресенье, 18 ноября 2012 г., 19:57:31 UTC+4 пользователь Stepan Koltsov написал:

[Artem Grinblat]

Is there a rethrow in clang? It might interfere with the first option.

воскресенье, 18 ноября 2012 г., 19:57:31 UTC+4 пользователь Stepan Koltsov написал:

Hi, Artem.

[Stepan Koltsov]

Artem,

You meant "rethrow in clay"?

I added rethrow statement today: https://github.com/jckarter/clay/commit/9e34f13a577bddea64c4b21dbcf5559764f143b8

Stepa