Re: Benefits of Dynamic Typing

Joachim Durchholz <jo@xxxxxxxxxxxxx> writes:

> The best I can do is to compare with projects I have been involved
> with - and it never occurred that there was a *need* to handle errors
> differently.

Perhaps this was accidental: I anticipated more errors to be fatal
when I was designing that, and it turned out that in most cases it's
easy to return some dummy value (or a designated value for an error)
and continue.

I just listed all cases where my code did catch specific exceptions
(i.e. excluding generic constructs which catch exceptions around some
body but do the same thing for any exception). Even if some of them
could be avoided by structuring the program differently, I prefer to
be less constrained and have more options available.

> You need an exception trace, i.e. a list of all functions that the
> exception propagated through when it was caught.
> The exception trace is almost identical to a stack trace most of the
> time, though there can be complications if another exception occurs
> during exception handling, or if code handles an exception and
> throws another one (in the latter case, it's still useful to carry
> information on the original exception around).

In my implementation the stack is physically unwound when an exception
handler finishes, not when it starts. This means that if an exception
handler throws another exception (or rethrows the same exception),
then the stack trace will include the original trace which led to the
previous exception, plus the trace inside the exception handler, plus
anything after that.

The trace is materialized as an object from scanned stack only when
needed, usually after an exception escapes the toplevel.

> However, this exception trace is just debugging information and can
> be carried in string (text) form. The software isn't supposed to
> base decisions on the contents of the exception trace.

Indeed it's suitable only for ultimately showing it to a human.
I don't want programs to make decisions basing on the stack trace.
But I do want - basing on the exception itself, which means it should
be something more than a string.

> Or the problem is something that might happen. In that case, throwing
> an exception isn't a good solution - you might be aborting all kinds
> of higher-level transactions you don't know about.

They are responsible for their cleanup in case the code they call
throws an exception. This is usually done by bracketing constructs
which guarantee that something is done no matter whether the given
code finishes normally or fails.

If exceptions are supported at all, no matter whether they are
machine-readable objects or text messages, then code must be prepared
for proper cleanup if they appear. Especially in a dynamically typed
language where various problems are not caught at compile time but
show up at runtime as exceptions.

> Or, the higher-level transactions would have to write exception
> handlers to make sure that their transactions are completed, and
> they'd have to inspect any exception that percolates up and check
> whether it's a failure or something they're supposed to handle.
> Which means they have to know what kinds of exceptions might come
> from the bowels of the lower layers,

No, they only need to know the kinds of exceptions they are supposed
to handle.

--
__("< Marcin Kowalczyk
\__/ qrczak@xxxxxxxxxx
^^ http://qrnik.knm.org.pl/~qrczak/
.

Relevant Pages

  • Re: VB6 error handling and stack trace?
    ... That code for generating a stack trace using the debug info compiled into ... VB exception handlers are only ... handler was declared. ... and I thought NT's core exception handling inherited the ...
    (microsoft.public.vb.general.discussion)
  • SqlDataAdapter.Fill returns results of previous command
    ... This code executes successfully at certain points in the application, ... I don't know what the cause of this exception is yet, ... stored procedure was indeed executed on the database. ... The trace shows that the last action on the db was the stored ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Intermittant Server Error reading an MS Access DB
    ... I narrowed down where the error occurs by writing to a trace file. ... An unhandled exception occurred during the execution of the ... > Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: FileNotFoundException when loading a dll I think is really there
    ... To trace what modules are being loaded by your application you can use ... ZH> below) to a 3D API (OSG) using the OsgDotNet C# to C++ wrappers. ... ZH> this exception is occuring. ... ZH> Using an app named FileMon I can watch my app try to load the dll's. ...
    (microsoft.public.dotnet.framework)
  • Re: Fehlersuche per Stack Trace
    ... the debugger seems to forget to switch to the exception callstack and instead ... daraus wieder ein Dump angestossen der dann funktioniert und somit den Trace ... sollte man wohl beim drittletzten Parameter von MiniDumpWriteDump IntPtr.Zero ...
    (microsoft.public.de.vc)
Loading