On Thursday, 6 November 2014 at 09:17:55 UTC, Jonathan Marler
wrote:
First, D has the capability to generate code that uses error
codes via registers or some global variable (note: I wouldn't
specify that a compiler should use a certain register for error
codes, the compiler is smart and will decide the best way to do
that).
Well, if it is that smart then it would be an optimization, but
that makes separate compilation harder.
So I believe what you're looking for is a standard mechanism
for functions to return errors and for the language to support
that standard with a nice syntax. I don't think this is a bad
idea, but this isn't really necessary since you can already do
these things, maybe in a more verbose syntax, but you can do
them without modifying the current language.
Well, but it requires wrapping. Google are not using exceptions
in C++, according to a presentation on cppcon, they are using a
"status-object" that requires errors to be handled or explicitly
ignored.
BUT: if you have noisy syntax for it, people will avoid using it.
One thing I like about your suggestion is you can specify if a
function's error code should be verified to be handled at
compile time. It would be nice as a library writer if you
could specify that the error MUST be handled by the caller.
That way you have some protection that users will use your
functions correctly.
Yes, I like the concept. You could have four different policies
for error handling:
1. no error
2. must be handled at once
3. must be handled sometime (collective handling)
4. optional handling
A function should throw an exception if it CAN NOT perform
the action indicated by it's name.
Walter has argued against web servers using exceptions to return
errors in REST applications because of the performance penalty…
So I think you need a third fast-unwind-exception feature… :-)
Which I have suggested before: you have a manger object and a
landing pad. When you throw "fast unwind" you jump to the landing
pad, let the manager object free all allocated resources and
reset the stack pointer.
Voila, fast unwinding!
(Basically a generalized version of region allocation with
language support.)
codes instead. What I do is prefix the function with "try".
You don't have to do that, but it helps me personally keep
track of what functions require explicit error checking. A
function named "tryWrite" lets the user know the function may
not write and they need to check somehow whether or not it
failed.
Yeah, such naming conventions can be useful. At some point I used
to append "_ok" to functions that returned boolean error values:
"if (!write_ok(…))…"
Typically in the "normal operation" of a program, especially
one you want designed to run fast, you will NEVER THROW AN
EXCEPTION.
And you want to not compile in exception support and omit
explicit stack frames. :-)
An exception being thrown isn't typically used as normal
"control flow". An exception is typically used to indicate an
"environment error".
I assume you used quotes because you agree that "environment
error" is underspecified and perhaps even indeterminate at the
failure point.
Beside, I don't really agree.
I think it is ok to throw whenever a web server cannot serve a
response to a request. No need to special-case the difference
between 500 and 404, the external entity can trigger both (and
the difference can be subtle).
You basically want uniformity and no special casing based on
subtle differences.
and expensive. You don't want to be throwing and catching
exceptions all over the place, but when you do have an
exception you want to capture as much info as possible even it
if incurs a huge runtime cost.
But I may want the same info on input related failed requests. If
someone is getting a 404 it might be a problem in the server too.
A function that returns error in "normal program operation"
should use the "try" mechanism and a function that always
succeeds unless some type of environmental error occurs can
just throw an exception.
The language should support clean programming. If you need to
unwind all the way to the root handler then why go through the
hassle of adding a spaghetti of conditionals?
Without fast and simple unwinding for aborting a request D will
not be suitable for webserver programming IMO.
