On Thu, Aug 29, 2013 at 8:57 AM, Matt Rice <[email protected]> wrote:
> Don't think that the following was covered in this thread, apologies > if I missed it. > ML's module system brings about a curious case with exceptions, > for an exception to be handled by name, it must not be hidden within > the module, but making the exception public in the module allows > callers to raise the exception, > > i'm told that you can sort of achieve this by having a function which > takes the exception as an argument, and returning a bool if it is the, > call this from the exception handler and re-raise on false > > handle exn => if isFooException then ... else raise exn > > while that does appear to work, it seems by re-raising other > exceptions we potentially obscure their origin. > > I sort of found it interesting in that it doesn't seem to jive with > the rest of the ML module system where there is a definite > hidden/opaque/public structure to it. FWIW i'm not really sure that the ability to suppress raising an exception has any practical value, because the raising process includes the source location of the raise thereby allowing one to differentiate between the same exception raised multiple times, where error codes being reused, do not (outside of a debugger). _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
