Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003959OCamlOCaml generalpublic2006-01-21 23:062014-09-04 00:25
ReporterMartin Jambon 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version3.09.0 
Target VersionundecidedFixed in Version 
Summary0003959: no exit on bad #use in ocaml scripts
DescriptionThe ocaml command or a custom toplevel, when used in non-interactive mode, does not stop when it encounters a directive with a valid name but an invalid argument:

1) Valid directive name, wrong argument (should exit):

[droopy] ~/tmp % cat blop.ml
#use "abc";;
print_endline "hello";;
[droopy] ~/tmp % ocaml blop.ml && echo success
Cannot find file abc.
hello
success

2) Wrong directive name (works as expected):

[droopy] ~/tmp % cat blop2.ml
#abcde "abc";;
print_endline "hello";;
[droopy] ~/tmp % ocaml blop2.ml && echo success
Unknown directive `abcde'.
Additional InformationThis problem is present at least in OCaml 3.08.4 and OCaml 3.09.1 (x86 Linux).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0012010)
gasche (developer)
2014-08-15 17:16

In fact the toplevel currently ignores any error arising from running a directive, as long as the directive has been found and is passed arguments of the expected type and arity. This applies to #use but also to #load for example.

Do we really want to change this behavior, though? It's not a very hard change to make, but I'm worried people could actually rely on it.

A use-case I had in mind is the following: when working in a project with several compilation units (say {a,b,c}.ml), I would often create a local .ocamlinit file with the #loads in dependency order:
  #load "a.cmo";;
  #load "c.cmo";;
  #load "b.cmo";;

Then, running a toplevel would put me in an environment where the modules of the project are available. But if one source file was being modified and wouldn't compile (or its compiled unit were out-of-date with its new dependencies), the script would still work until the relevant point, and leave me in a state where the dependencies were available, only not the failing file.


That's not a terribly important use-case and I'm fine with changing the behavior. I still wonder whether some other people rely on this in more important ways.
(0012011)
Martin Jambon (reporter)
2014-08-15 18:41

Outside of a REPL, it seems proper behavior that any invalid instruction would cause the program to fail.

Invalid instructions can and should be tolerated when the user is present to read the error messages and react if the program goes haywire. For that, the current behavior is fine.
(0012013)
gasche (developer)
2014-08-15 20:09

I just commited a first approach in a dedicated branch
  https://github.com/gasche/ocaml/tree/script-directives-failure [^]

the commit:
  https://github.com/gasche/ocaml/commit/df19b7aeabdb60990b98c3ebb04e5d0afbe0e10c [^]

the patch:
  https://github.com/gasche/ocaml/commit/df19b7aeabdb60990b98c3ebb04e5d0afbe0e10c.patch [^]


I think the patch works as you would expect. That said, it changes the public interface of toplevel directives (which may be added by external users, eg. ocamlfind's #require directive); it is a non-invasive change as I added a new exception that is not used so far:
  exception Directive_failure

It should make us pause and wonder what a good interface for this new feature (signalling errors) is. I would naturally add a (string option) argument to the exception, to let users optionally attach an error message.
  exception Directive_failure of (string option)

I wonder whether this is a bug and a feature. If we can include a patch (this one or an improved version) to "fix" the bug, it can go in 4.02. If we find out it's a new feature that needs design consideration, it would be better to commit in trunk only.
(0012014)
Martin Jambon (reporter)
2014-08-15 20:59

I like the proposed solution with the Directive_failure exception and no argument.

I don't see what we would gain from having an optional error message string in the exception since it can be printed out before raising the exception anyway. However it might be worth asking someone who's familiar with writing custom directives or custom OCaml toplevels.
(0012017)
dim (developer)
2014-08-18 11:05

Having the error message as argument of the directive instead of printing would allow a custom toplevel to format it differently, for instance print it in red.

- Issue History
Date Modified Username Field Change
2006-01-21 23:06 Martin Jambon New Issue
2006-03-29 16:32 doligez Status new => acknowledged
2006-03-29 16:42 doligez Category Incoming => OCaml general
2012-07-11 16:46 doligez Target Version => 4.01.0+dev
2012-07-31 13:37 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-11 14:20 doligez Target Version 4.00.1+dev => 4.00.2+dev
2013-07-02 16:19 doligez Target Version 4.00.2+dev => 4.01.0+dev
2013-07-02 16:20 doligez Status acknowledged => confirmed
2013-07-24 11:51 doligez Target Version 4.01.0+dev => 4.01.1+dev
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-08-15 17:16 gasche Note Added: 0012010
2014-08-15 17:52 gasche Status confirmed => feedback
2014-08-15 18:41 Martin Jambon Note Added: 0012011
2014-08-15 18:41 Martin Jambon Status feedback => new
2014-08-15 20:09 gasche Note Added: 0012013
2014-08-15 20:24 gasche Status new => confirmed
2014-08-15 20:59 Martin Jambon Note Added: 0012014
2014-08-18 11:05 dim Note Added: 0012017
2014-08-18 15:13 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker