emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal to make null string handling more emacs-y


From: Eli Zaretskii
Subject: Re: proposal to make null string handling more emacs-y
Date: Fri, 27 Apr 2012 09:36:17 +0300

> Date: Thu, 26 Apr 2012 21:17:36 -0700
> From: Steve Yegge <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, address@hidden
> 
> But type errors are for *developers*.  They are supposed to happen at
> compile time.  When you're running the byte compiler or the unit tests, you
> want it to fail loudly and early.

This is Lisp, not C++ or even Java.  Some Lisp code is never compiled
at all.  A notable example is the code you put in .emacs.

> But when you ship the software, and it's in the hands of end-users
> who may not be able to debug it, then unless it's running a nuclear
> reactor or an airplane, you want the software to be robust.  Your
> browser shouldn't crash because of a misbehaved site; your web page
> shouldn't fail to load because of a misbehaved widget; your CAD
> program shouldn't stop functioning because of a misbehaved polygon.
> Yes, the resulting bug will be annoying, but it's far less annoying
> than having your work interrupted altogether.

I don't think you can have an interpreted language without runtime
exceptions.  In Lisp, if you want robust programs, you need to catch
exceptions and do something reasonable.  Asking to avoid exceptions
altogether is IMO impractical.

> Similarly, I see a whole bunch of file-name manipulation functions that
> accept the empty string as an argument.  But the empty string has no
> semantic meaning whatsoever as a valid filename.  Without any semantic
> meaning, it's arguably a bug to pass one in.

The usual Emacs semantics for an empty file name is that it stands for
the current directory.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]