On Tue, 06 Mar 2012 12:14:56 +0100, Don Clugston <d...@nospam.com> wrote:
On 04/03/12 04:34, Walter Bright wrote:
On 3/3/2012 6:53 PM, Sandeep Datta wrote:
It's been there for 10 years, and turns out to be a solution looking
for a
problem.
I beg to differ, the ability to catch and respond to such asynchronous
exceptions is vital to the stable operation of long running software.
It is not hard to see how this can be useful in programs which depend
on plugins
to extend functionality (e.g. IIS, Visual Studio, OS with drivers as
plugins
etc). A misbehaving plugin has the potential to bring down the whole
house if
hardware exceptions cannot be safely handled within the host
application. Thus
the inability of handling such exceptions undermines D's ability to
support
dynamically loaded modules of any kind and greatly impairs modularity.
Also note hardware exceptions are not limited to segfaults there are
other
exceptions like division by zero, invalid operation, floating point
exceptions
(overflow, underflow) etc.
Plus by using this approach (SEH) you can eliminate the software null
checks and
avoid taking a hit on performance.
So in conclusion I think it will be worth our while to supply
something like a
NullReferenceException (and maybe NullPointerException for raw
pointers) which
will provide more context than a simple segfault (and that too without
a core
dump). Additional information may include things like a stacktrace
(like
Vladimir said in another post) with line numbers, file/module names
etc. Please
take a look at C#'s exception hierarchy for some inspiration (not that
you need
any but it's nice to have some consistency across languages too). I am
just a
beginner in D but I hope D has something like exception chaining in C#
using
which we can chain exceptions as we go to capture the chain of events
which led
to failure.
As I said, it already does that (on Windows). There is an access
violation exception. Try it on windows, you'll see it.
1. SEH isn't portable. There's no way to make it work under non-Windows
systems.
2. Converting SEH to D exceptions is not necessary to make a stack trace
dump work.
3. Intercepting and recovering from seg faults, div by 0, etc., all
sounds great on paper. In practice, it is almost always wrong. The only
exception (!) to the rule is when sandboxing a plugin (as you
suggested). Making such a sandbox work is highly system specific, and
doesn't always fit into the D exception model (in fact, it never does
outside of Windows).
Responding to traps is one of the very few examples I know of, where
Windows got it completely right,
and *nix got it absolutely completely wrong. Most notably, the hardware
is *designed* for floating point traps to be fully recoverable. It makes
perfect sense to catch them and continue.
But unfortunately the *nix operating systems are completely broken in
this regard and there's nothing we can do to fix them.
Yeah, it's true for FPU traps. You need signals+longjmp to handle them.
Though with SEH you shouldn't forget to fninit before continuing or your
FPU stack might overflow.
