A better exception system has been on the wish list for a long time. I agree that changing the errno stuff to exceptions before we have that would be a mistake. Any takers to do something about it?
I think a more "pike:ish" way to implement it is to use recognition constants instead of type inference. That makes it simpler to fix correct exception objects in dynamic environments, and it follows the "looks-like" rather than "is-a" philosophy of type comparisons in Pike.
Anyway, the difference from your proposal would be mostly syntactic in practice:
try (Exception e) { Stdio.format_filesystem("/dev/hda2", "ext5"); } catch (e->invalid_file_system_type) { // invalid file system type } catch (e->no_permission || e->not_mounted) { // no permission or filesystem mounted }
Note that the exception variable is specified in the try clause, much like how foreach variables are specified or declared in foreach clauses. The catch clauses take normal expressions, which means full freedom in writing complex catch conditions.
One could perhaps support a shorthand syntax to avoid handling the exception object explicitly:
try { Stdio.format_filesystem("/dev/hda2", "ext5"); } catch invalid_file_system_type { // invalid file system type } catch no_permission, not_mounted { // no permission or filesystem mounted }
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-01 16:56: Subject: Re: throw or return
I kind of agree with Alexander - the current exception system is not useful as an error handling mechanism. Also I'm sure it's less efficient than using a return codes.
That said, I also wouldn't want Pike programming to become the nightmare Java is in terms of requiring try / catch for "all" system calls. One of the really annoying things when programming java IMHO. If a file fails to open when I call "open", return 0. If a file fails to open if I use Stdio.File("file"), there probably should be an exception thrown (since there is no other mechanism to signify an error in a constructor).
For methods requiring multiple error conditions, I much rather prefer integers to be returned. I.e:
switch(Stdio.format_filesystem("/dev/hda2", "ext5")) { case Stdio.EFILSYS: // invalid file system type break; case Stdio.EACCESS: case Stdio.EMOUNTED: // no permission or filesystem mounted break; }
etc. Similar to the concept of errno I suppose. _If_ we had a working exception system, and could write code such as this, it wouldn't be bad either:
try { Stdio.format_filesystem("/dev/hda2", "ext5"); } catch(Stdio.FileSystemTypeException e) { // invalid file system type } catch(Stdio.MountedException | Stdio.AccessException e) { // no permission or filesystem mounted }
If on the other hand we would have to write:
try { Stdio.format_filesystem("/dev/hda2", "ext5"); } catch(Stdio.FileSystemTypeException e) { // invalid file system type } catch(Stdio.AccessException e) { // no permission } catch(Stdio.MountedException e) { // filesystem mounted }
It'd be worse and we'd get the Java nightmare. If you can't handle two distinctly different exceptions in the same block of code, without resorting to some generic Exception, it's a broken system. Of course all this is purely hypothetical since we actually don't have a well defined exception system like this anyway. Given the current exceptions, I definitely vote for return codes whenever practical.
/ David Hedbor