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
Previous text:
2003-10-01 21:19: Subject: Re: throw or return
For the latter syntax I see no gain in comparision to using:
Exception e = catch { Stdio.format_filesystem("/dev/hda2", "ext5"); } if(e) { if(e->invalid_file_system_type) { // invalid file system type break; } if(e->no_permission || e->not_mounted) { // no permission or filesystem mounted break; } }
I.e there would really be no change from the current syntax at all, other than some minor syntax changes.
And perhaps all that is needed is catch to return something more useful than the current array. However I like the idea of being able to use a switch or switch-like statement for checking exceptions (for the simple reason that often it leads to nicer code).
Another question is how would you throw an exception like this?
Exception error = Exception(); // creates new exception with current backtrace error->invalid_file_system_type = 1; throw error;
This is clumpsy. So..
throw Exception("invalid_file_system_type");
This doesn't allow for inheritance. So..
Throw InvalidFileSystemTypeException();
Allows for inheritance and is just one line but could also possibly suffer from the java "too long names on classes" issue. What I don't think anyone wants is a case where throwing an exception becomes a multi-line problem, and I think we all want exception inheritance.
I still don't REALLY see the benefit of using:
e->some_obscure_string
rather than handling it by class name, i.e
SomeObscureException
then your own exception could inherit correctly from other exceptions and things would work ok. I.e
class MyFileSystemException { inherit Exception.FileSystem; ... }
class FileSystem { inherit IOException; ... }
class IOException { inherit Exception; ... }
this is one thing that actually does work well in Java. If you have som alternative idea how exceptions will work, please point that out. I think the basic issue of how exceptions are created greatly would affect how exceptions should be handled.
/ David Hedbor