[Ur] Exceptions handling

[Adam Chlipala]

Vladimir Shabanov wrote:
> 2010/8/24 Adam Chlipala<adamc at impredicative.com>:
>    
>> Vladimir Shabanov wrote:
>>      
>>> And there is another way to check DML errors -- another function dml'
>>> can be adder which returns option string instead of error page, e.g.
>>>      result<- dml' (...);
>>>      case result of
>>>            None =>    return "ok"
>>>            Some e =>    return strcat("dberror: ", e)
>>>
>>>        
>> I like this suggestion.  The key issue is deciding which database errors
>> should be returned in this way.  An error like "lost connection to server"
>> should still abort execution, IMO, since it's outside of the abstraction
>> that Ur/Web is meant to present to the programmer.  A corollary issue is
>> which methods should be used with each database system's C library to filter
>> out the appropriate errors.
>>      
> I think that constraint violations should be returned (ideally with
> name of constraint), other errors (except errors that Ur's runtime
> can't handle -- like connection issues) can be just returned as string
> so they still can be handled even without native Ur support.
>    

I've started implementing this.  Everything works, save that the 
semantics differs between Postgres and MySQL/SQLite.  Postgres won't let 
you continue using a transaction after one command has failed, whereas 
MySQL and SQLite allow many errors within one transaction.  (Remember 
that every Ur/Web page execution is implicitly inside a single 
transaction.)  What does everyone think about whether that semantics is 
acceptable for Ur/Web?  The more liberal semantics can be implemented 
for Postgres using savepoints, but it would decrease performance.  If no 
one would want to keep running SQL after an error, then there doesn't 
seem to be a reason to do more work.

Personally, I'm in favor of never using this new feature, anyway, but 
I'm interested in what y'all who argued for it think. :)