Re: throw or return

For the latter syntax I see no gain in comparision to using:

You'll get an implicit throw, which is the problem today.

/ Martin Nilsson (saturator)

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