a) it's shorter to write e.g. err->is_foo_error rather than Program.inherits(object_program(err), FooException), and
If we decide to make the exception system inherit-based we would of course create a shorter way to perform that operation, so this is quite a non-argument.
/ Martin Nilsson (saturator)
Previous text:
2003-10-01 22:04: Subject: Re: throw or return
I still don't REALLY see the benefit of using:
e->some_obscure_string
rather than handling it by class name, i.e
SomeObscureException
The benefit is that the catch conditions become normal expressions which are much more powerful than type dispatch. Most often they would only check for a constant, but they might do other stuff. E.g:
try { blabla(); } catch (Exception err) { case err->is_io_error && err->file == the_interesting_file: // There was some I/O error with the file we're interested in here. break; }
then your own exception could inherit correctly from other exceptions and things would work ok. I.e
Yes, we should have a class tree that uses inheritance to group errors together. The best way to get a suitable set of constants in the exception objects is actually to inherit them. The point with recognizing them through constants and not the inherit relations directly is
a) it's shorter to write e.g. err->is_foo_error rather than Program.inherits(object_program(err), FooException), and b) it's possible to define error classes even in cases where the errors they should be compatible with aren't available in the namespace at compile time.
/ Martin Stjernholm, Roxen IS