Register based error-handling?

[via Digitalmars-d]

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.