MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: [SERVER] Customizable exceptions

Christopher Unkel:
> try
>   "Code that can raise a division by zero exception";
> except ($exceptions.divbyzero)
>   "Handle overflow exception";
> endtry
> 
> is [not] really much of an improvement; instead of having to remember what 
> error foo verb/built-in can raise, we have to remember what prop on 
> $exception it raises.  Not so much better.

and Andy Bakun wrote:
> What do you 
> suggest is raised when read() is tried on a closed connection with no 
> pending lines? .connection_closed_and_no_pending_input?  E_INVARG says 
> this.  Apparently, this is the only time E_INVARG is raised, so it has 
> an unambigious meaning in terms of read().

> I agree though, some bf's, perhaps open_network_connection, could provide
> more description as to what the error was (not that it matters, since if it
> couldn't open the connection, the error raised described what is wrong.

My point is not that $exception.error_name will be more efficient to use 
than E_*, or that the existing errors do not manage (barely) to uniquely 
describe each kind of possible error.  My point is that the current E_* 
mechanism is not scalable at all.  Every time a new built-in function is 
introduced, or the error-reporting capabilities of an existing function 
enhanced, we try to somehow map those errors into the existing ones.  
The result is ambiguity (to which error does this E_QUOTA really 
correspond?) and lack of clarity (E_INVARG here means 
one thing, E_INVARG there means something else...).

I don't want to be limited by a small set of possible error values.
Pavel made huge strides toward a workable error/exception mechanism for 
MOO with the try/endtry, raise(), and 'EXPR1 ! CODES => EXPR2'
additions to the language, and I would like to see this progress taken 
one step further -- to obsoleting MOO error values entirely, and 
replacing them with a more scalable, portable, and readable solution.

Chris Unkel also wrote:
> Hmm.  It seems to me that this would encourage people to use either
> numbers (which are even less descriptive than the error values) or strings
> as error conditions.

and Andy Bakun wrote:
> I see the power of that, but what difference does it make what values the
> server raises for exceptions, especially if you are going to have it raise
> something described as *.divide_by_zero (no matter what value exists in 
> that prop), which is really what E_DIV is saying anyway.

Actually, I don't really care what values people use -- it's not 
important, so long as they're distinct.  I would use the integers, and 
in fact set it up so that for each pname in properties($exception),

   $exception.(pname) = pname in (properties($exception));

and then code $handle_uncaught_error to map these integers back into the 
original property name or more verbose error descriptions.  But 
people could obviously use whatever they feel like, including the 
current defaults.

Andy Bakun also wrote:
> Is this an attempt to get rid of code like:
>  try
>    x = open_network_connection(..);
>  except (E_PERM)
>    return notify(who, "not allowed to make connections");
>  except (E_QUOTA)
>    notify(who, "not enough resources... trying again in a few mintues");
>    fork (60) this:(verb)(@args); endfork return;
>  except (E_INVARG)
>    return notify(who, "they didn't want our connection :(");
>  endtry
>  try
>    try
>      line = read(x);
>    except (E_INVARG)
>      return notify(who, "nothing to read from connection");
>  finally
>    return boot_player(x);
>  endtry
>and instead do something like this:
>  try
>    try
>      x = open_network_connection(...);
>      line = read(x);
>    except ($exceptions.permission_denied)
>      return notify(who, "not allowed to make connections");
>    except ($exceptions.out_of_resources)
>      notify(who, "not enough resources... trying again in a few mintues");
>      fork (60) this:(verb)(@args); endfork return;
>    except ($exceptions.connection_denied)
>      return notify(who, "they didn't want our connection :(");
>    except ($exceptions.no_pending_input)
>      return notify(who, "nothing to read from connection");
>    endtry
>  finally
>    boot_player(x);
>  endtry
>
> Essentially wrapping all the main body of code in one try/endtry? Mmh...
>

This would be one benefit.  Notice that these changes aren't merely 
cosmetic: The code is not only easier to read, but also easier to 
maintain since it is now possible to distinguish between the two 
different kinds of E_INVARG encountered (one meaning connection_denied, 
one meaning no_pending_input) without altering the program's logical flow 
as in the original code snippet.

Also, now that we can add custom builtin functions with ease and still 
port the database to other servers lacking them, it would be nice to be 
able to add custom errors (often to go along with these builtin 
functions) and still be able to port the database (or more frequently, a 
few objects) to others having different errors.  This would also be 
facilitated by the use of named $exceptions.


michael
brundage@ipac.caltech.edu
References:
Home | Subject Index | Thread Index