DConf talk : Exceptions will disappear in the future?

[H. S. Teoh]

On Thu, Jan 07, 2021 at 07:00:15PM +0000, sighoya via Digitalmars-d-learn wrote:
> On Thursday, 7 January 2021 at 18:12:18 UTC, H. S. Teoh wrote:
[...]
> > Wrong. Out of memory only occurs at specific points in the code
> > (i.e., when you call a memory allocation primitive).
> 
> What about pushing a new stack frame on top/bottom of the stack? This
> is very implicit. I don't talk about a theoretical Turing machine with
> unbounded memory, rather about a linear bounded automaton with finite
> memory.
> What happens if stack memory isn't available anymore?

In all non-trivial OSes that I'm aware of, running out of stack space
causes the OS to forcefully terminate the program. No non-toy compiler I
know of checks the remaining stack space when making a function call;
that would be an unreasonable amount of overhead. No
performance-conscious programmer would accept that.


[...]
> > This tells me that you do not understand how compiled languages work.
> 
> Traditionally, inlining means the insertion of code from the callee
> into the caller, yes.
> Imagine now, that the source code of the callee isn't available
> because it is already compiled and wrapped in a dynlib/static lib
> before (and now you link to that dynlib/static lib), then you can't
> inline the source code, but you can inline the binary code of the
> callee.

This is not inlining, it's linking.


> For this to be "optimize-safe" regarding exceptions you need to store
> some meta information, e.g. the line number of all direct thrown
> exceptions in it, during the compilation of the callee in the
> dynlib/static lib for any caller outside the dynlib/static lib.

I don't understand what's the point you're trying to make here. What has
this got to do with how exceptions are thrown?  Any code, exception or
not, exports such information to the linker for debugging purposes. It
does not directly relate to how exceptions are implemented.


[...]
> > All of this information is already available at compile-time. The
> > compiler can be easily emit code to write this information into some
> > error-handling area that can be looked up by the catch block.
> 
> Yes, but the line number is changing when inlining the code,
[...]

???!  How does inlining (or linking) change line numbers?!  Whether or
not something is inlined has nothing to do with what line number it was
written in.  The compiler does not edit your source code and move lines
around, if that's what you're trying to say.  That would be absurd.


> > Also, you are confusing debugging information with the mechanism of
> > try/catch.
> 
> So you only want to output line numbers in stack trace during
> debugging and not in production code?

"Debugging information" can be included in production code. Nothing
stops you from doing that.  And this has nothing to do with how
try/catch is implemented.


T

-- 
Живёшь только однажды.