(define-exception) fails with (repr :lisp)

[Jason94]

The documentation for define-exception says "define-exception: Defines an exception type. Other than its name, the syntax is identical to define-type." To me, that suggests that it's valid to use with a (repr :lisp). And this could be important because you might be calling Coalton code in Lisp that throws that exception, so the Lisp representation needs to be well defined so it's catchable in a handler-case.

However, it doesn't compile. At the very least, it should probably fail with a more helpful message:

  (repr :lisp)
  (define-exception MyException
    (MyFailedException String))
==>
  error: 
    (during macroexpansion of (COALTON-TOPLEVEL
      (DEFINE-EXCEPTION THREADINGEXCEPTION
        ...)
      ...))
    Internal coalton bug: parse-toplevel-form indicated that a form was parsed but did not consume all attributes
    
    If you are seeing this, please file an issue on Github.

This works in release mode like you'd expect, so it seems like exceptions are getting compiled with (repr :lisp) guarantees. But I'm not 100% sure of all the nuances that could be footguns there. So "fixing" this could just be adding another line to the docs and improving the error message to say something like "Invalid repr declaration detected. define-exception is always compiled with Lisp representation, so it cannot receive a manual representation specifier."

(cl:in-package :cl-user)
(defpackage :test
  (:use
   #:coalton
   #:coalton-prelude
   ))

(in-package :test)

(named-readtables:in-readtable coalton:coalton)

(coalton-toplevel

  (define-exception MyException
    (MyFailure String))

  (declare fail-coal (Integer -> Integer))
  (define (fail-coal x)
    (if (zero? x)
        (throw (MyFailure "We failed"))
        x))

  (declare handle-lisp (Integer -> Integer))
  (define (handle-lisp x)
    (lisp Integer (x)
      (cl:handler-case (call-coalton-function fail-coal x)
        (MyException/MyFailure (e)
          (cl:format cl:*error-output* "Failed: ~a~%" e)
          0)))))

(coalton (handle-lisp 0))

[c-kloukinas]

Should coalton code ever throw an exception? Isn't one supposed to use optional, etc in coalton instead of exceptions?

[Jason94]

The short answer is yes, because otherwise you have to wrap everything in an optional/result. Imagine having to do this every time:

(match (/ x 2)
  ((Err (DivideByZeroException))
   (trace "Impossible code encountered: 2 cannot be 0")
   0)
  ((Ok x)
   x))

Furthermore there's certain situations where exceptions can throw without a function actually returning anything. Another thread could trigger an asynchronous exception, the heap could run out of space (although if that happens you're kind of cooked), a weak pointer could reference a garbage collected object, etc.

Beyond that, there are valid cases where you want to throw instead of return a value. We discussed this recently in the dev channel of the discord. But the TLDR is that if you're only passing back a success/failure state in the return value, but no other information, it makes it really easy for the user of the function to forget to let failures go unhandled. Imagine writing this code if with-open-file doesn't throw, and just returns:

(let result = (do-something))
(with-open-file ("my-log-file.txt" Output ErrorIfDoesntExist)
  (write-line result))