That's probably a good thing to do so that any strange octave_value object, like a 'magic colon' or 'lazy index', won't cause the save process to abort.

It still might be worthwhile to override the base save_ascii, load_ascii, save_binary, load_binary in ov-classdef.cc because then you could tailor the warning message.  Instead of

warning: octave_base_value::save_ascii(): wrong type argument 'object'

you could have something like that done for java objects

save: unable to save java objects, skipping

or for onCleanup objects

warning: onCleanup: load and save not supported

@jwe: It definitely would be a good idea to have placeholder save functions that issue a warning, but allow any other variables to be saved.  I did that for java objects recently in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/b22528fd3deb).  An important issue is that when Octave is in the midst of crashing it attempts to save all variables to the octave-workspace file.  If you happen to have a classdef object in the workspace then the saving of variables itself has an error and the entire workspace is lost.

In https://lists.gnu.org/archive/html/octave-maintainers/2014-08/msg00180.html, jwe mused whether adding support for classdef objects for all file formats might be a waste of time, and whether this would be a good time to deprecate some of the supported file formats, or only add support for new types to certain file formats, etc.

So load/save of classdef objects may or may not need to be implemented in all possible file formats, it may be worth further discussion.