[Ur] 1/0 stopping server?

Ron de Bruijn rmbruijn at gmail.com
Mon Nov 28 05:49:50 EST 2011


Op 28-11-11 08:48, Marc Weber schreef:
> Try this simple app:
>
>    fun div_by_zero r: transaction page =
>    let
>      val a:int = readError r.A
>      val b:int = readError r.B
>    in
>            return<xml>
>            <head>  <title>Hello world!!</title>  </head>
>            <body>
>              {[a /b ]}
>            </body>
>          </xml>
>    end
>
>
>
>    fun main (():unit) : transaction page =
>      return<xml>
>        <head>  <title>Hello world!!</title>  </head>
>        <body>
>          <form>
>          <textbox{#A}/>
>          <textbox{#B}/>
>          <submit action={div_by_zero}/>
>          </form>
>        </body>
>      </xml>
>
> then type 1 for #A and 0 for #B. The standalone server will quit with:
>    zsh: floating point exception  ./binary_search_tree.exe -p 8082
>
> Given that the server should keep state and can push data to clients
> can you really call this "production ready"?
Technically he called it 'usable for Real Work'. People release web-browsers too 
and they too are technically not 'production ready' (considering the vast 
numbers of security problems that have been identified in them (and which likely 
still remain)).
>
> If the server does not quit - is there a chance to find such a problem fast in
> huge web apps without stack trace?
I would say the approach is the same with fromJust errors in Haskell. The hack 
in Haskell is to use a preprocessor to rewrite such calls to calls to similar 
functions including source lines for example. In the case of / the same approach 
could help or otherwise a solution based on either modifying the compiler or 
writing a real source to source transformation. All come down to the same thing: 
don't call primitives that cause such problems directly.
>
> Or is the problem me using the standalone server?
I'd the say the problem is that the resulting binary has even the possibility of 
crashing because of this kind of problem. Exiting with a stack-trace would be 
fine, but there is no reason the main process should exit just because in some 
tiny function in some module there is a small problem. It should return some 
kind of error page while allowing the user to visit other pages.
>
> Marc Weber
>
> _______________________________________________
> Ur mailing list
> Ur at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur


-- 
Best regards,
   Ron de Bruijn



More information about the Ur mailing list