The title says it all already—well almost:)
In particular, I'm interested in the functions in modules Sys and Unix.
The "Unix system programming in OCaml" book (available here) states:
1.3 Error handling
Unless otherwise indicated, all functions in the Unix module raise the exception Unix_error in case of error.
exception Unix_error of error * string * string
[...]
Finally, the first argument of the exception is an error code indicating the nature of the error. It belongs to the variant type error:
type error = E2BIG | EACCES | EAGAIN | ... | EUNKNOWNERR of int
So far, so good, but ... which function can raise which error?
Which ones can, say, raise Unix_error(EAGAIN,_,_) and which ones can't?
Do I have to look into the implementation or is there a readily available list?
OCaml is just passing along the Unix error. The possible errors for each operation are in the Unix documentation. In fact this is documented reasonably well on the Unix-like systems I use. You can try man 2 chmod from the command line, for example.
However, the possible causes of each error (the inverse relation) is not documented so well (or at all) in my experience.
Related
So the issue is that, for using autotuning (like optuna) with AllenNLP, the suggested practice is to use, in jsonnet scripts, references to environment variables, and then to set up a study to modify those parameters.
That works fine, when the values are integers or floating points. For integers, you use std.parseInt(std.extVar(varname)), for floating point numbers, you use std.parseJson(std.extVar(varname)).
But if I want to change, say the optimization technique in my tests between "adam", "sparseadam", "adamax", adamw", etc. or change the type of RNN I am using, there does not appear to be an easy way to do that.
It would seem that you should be able to do std.extVar(varname) in that case without wrapping it inside a parseJson() or parseInt(), but that returns an error. Has anybody else had that problem and how did you get around it?
Just to add to this, I am trying this with three different string parameters. Here is the jsonnet for the first one, "bert_vocab":
local bert_vocab=std.extvar('bert_vocab');
Error message:
486 ext_vars = {**_environment_variables(), **ext_vars}
487
--> 488 file_dict = json.loads(evaluate_file(params_file, ext_vars=ext_vars))
489
490 if isinstance(params_overrides, dict):
RuntimeError: RUNTIME ERROR: field does not exist: extvar
/bigdisk/lax/cox/jupyter/bert_config.jsonnet:28:18-28 thunk <bert_vocab>
/bigdisk/lax/cox/jupyter/bert_config.jsonnet:61:22-32 object <anonymous>
/bigdisk/lax/cox/jupyter/bert_config.jsonnet:(59:16)-(63:12) object <anonymous>
/bigdisk/lax/cox/jupyter/bert_config.jsonnet:(58:21)-(64:10) object <anonymous>
/bigdisk/lax/cox/jupyter/bert_config.jsonnet:(56:19)-(65:8) object <anonymous>
During manifestation
I also tried various "string escaping functions" like here (but none of the string escaping functions work either:
local bert_vocab=std.escapeStringBash(std.extvar("bert_vocab"));
I can do the following to verify that the os environment variable is set:
os.environ['bert_vocab'] returns 'bert-base-uncased'
(I don't know AllenNLP, only Jsonnet.)
ExtVars can be arbitrary Jsonnet values (numbers, floats, strings, arrays, objects, functions or nulls).
Judging from the examples you brought up, AllenNLP passes the parameters as strings and you need to do the parsing. In such case it should be possible to just use "naked" std.ExtVar to get a string.
I have a use case for joblib's Parallel, delayed. I have included some feature that terminates a worker under certain conditions. However, when I do that, I am randomly yielding JoblibWebdriverException, Multiprocessing exception, JoblibURLerror, or just error.
To my great amusement, I don't find any section on how to (define?)/catch Exceptions in the docs.
When I do:
try:
Parallel(delayed(function))
except (JoblibWebdriverException | error | 'Multiprocessing exception'):
# written with separate excepts in original code
log_errors()
I yield name JoblibWebdriverException not defined followed by:
---------
Sub-process traceback
---------
Multiprocessing exception:
(trace stack)
How to catch undefined joblib Exceptions when using Parallel in python?
I would recommend using concurrent.Futures which has robust support for Exception handling. joblib is notorious for not being able to raise Exceptions from child processes to the main thread due to way the multi-processing is set up.
I'm struggling a little bit to raise exceptions the way I'm used to coming from a C# background.
I have a utility function that expects input values to be in a very specific range, as defined by an external standard. If a value is supplied outside of that range (and there is one value in the middle of the range that is also invalid), then I want to raise an exception to the caller so that they break.
From what I can tell, the syntax is raise Invalid_Argument;
But- is it possible to supply a message with the exception? e.g. the Invalid_Argument exception is somewhat self-explanatory, but I could see further detail specifying what was wrong with the argument. How do I write a brief error message to be stuck into the exception?
It used (Ada 95) to be you had to write
Ada.Exceptions.Raise_Exception (Invalid_Argument’Identity,
"message");
(see Ada95RM 11.4.2(6)) but since Ada 2005 you’ve been able to say
raise Invalid_Argument with "message";
(A2005RM 11.3).
Note that the string part is a string expression, so you can add something to describe the actual invalid value if that would be useful.
First, you can define a [sub]type
[sub]type Valid_Range_For_X is [Integer] range 23 .. 2001;
This will catch most invalid values automatically. If you're using Ada 12, you can add
[sub]type Valid_Range_For_X is [Integer] range 23 .. 2001 with
Dynamic_Predicate => Valid_Range_For_X /= 42;
which will catch the internal invalid value as well. It's usually better to let the language do such checks for you than to do them manually.
If you're using an earlier version of Ada, then you'll have to manually check for the internal value. I usually prefer fine-grained exceptions to a general exception used for many things, differentiated by the exception message. So I would raise something like
X_Is_42
rather than
Invalid_Argument with "X is 42"
This makes it easier to distinguish the 42 case from the (often many) other kinds of invalid arguments. I realize not everyone agrees with this.
I am currently developing geotiff reading and writing functions for octave using .oct files. I went through the octave documentation but could not find much on throwing exceptions. Does that mean I can throw exception the way I do it in C++ by just simply writing throw "error message"?
There are two ways, admittedly they are documented in two utterly separate places, not cross-linked/cross-referenced, which makes no sense, and if you didn't know the function/keyword you wouldn't find them:
error() raises an error, which stops the program. See 12.1 Raising Errors.
error("[%s] Here be wyrms", pkgname)
assert() both tests the condition then raises the error() with a customizable message (so don't do if (cond) ... error(...) ... endif).
See B.1 Test Functions.
% 1. Produce an error if the specified condition is zero (not met).
assert (cond)
assert (cond, errmsg)
assert (cond, errmsg, …)
assert (cond, msg_id, errmsg, …)
% 2a. Produce an error if observed (expression) is not the same as expected (expression); Note that observed and expected can be scalars, vectors, matrices, strings, cell arrays, or structures.
assert (observed, expected)
% 2b. a version that includes a (typically floating-point) tolerance
assert (observed, expected, tol)
See also the command fail()
Yes, you could just use something like
error ("mynewlib: Hello %s world!", "foo");
to signal errors which are catched and viewed.
(Personally I think such questions should really go to the GNU Octave mailing list where you'll find the core developers and octave-forge package maintainers).
I guess you want to build a wrapper around libgeotiff? Have a look at the octave-image package! Where do you host your code?
./examples/code/unwinddemo.cc might also be interesting for you. It shows how to use unwind_protect and define user error handlers.
http://hg.savannah.gnu.org/hgweb/octave/file/3b0a9a832360/examples/code/unwinddemo.cc
Perhaps your function should then be merged into the octave-forge mapping package: "http://sourceforge.net/p/octave/mapping/ci/default/tree/"
I find myself trying to convert constructor parameters to their right types very often in my Python programs. So far I've been using code similar to this, so I don't have to repeat the exception arguments:
class ClassWithThreads(object):
def __init__(self, num_threads):
try:
self.num_threads= int(num_threads)
if self.num_threads <= 0:
raise ValueError()
except ValueError:
raise ValueError("invalid thread count")
Is this a good practice? Should I just don't bother catching any exceptions on conversion and let them propagate to the caller, with the possible disadvantage of having less meaningful and consistent error messages?
When I have a question like this, I go hunting in the standard library for code that I can model my code after. multiprocessing/pool.py has a class somewhat close to yours:
class Pool(object):
def __init__(self, processes=None, initializer=None, initargs=(),
maxtasksperchild=None):
...
if processes is None:
try:
processes = cpu_count()
except NotImplementedError:
processes = 1
if processes < 1:
raise ValueError("Number of processes must be at least 1")
if initializer is not None and not hasattr(initializer, '__call__'):
raise TypeError('initializer must be a callable')
Notice that it does not say
processes = int(processes)
It just assumes you sent it an integer, not a float or a string, or whatever.
It should be pretty obvious, but if you feel it is not, I think it suffices to just document it.
It does raise ValueError if processes < 1, and it does check that initializer, when given, is callable.
So, if we take multiprocessing.Pool as a model, your class should look like this:
class ClassWithThreads(object):
def __init__(self, num_threads):
self.num_threads = num_threads
if self.num_threads < 1:
raise ValueError('Number of threads must be at least 1')
Wouldn't this approach possibly fail very unpredictably for some
conditions?
I think preemptive type checking generally goes against the grain of Python's
(dynamic-, duck-typing) design philosophy.
Duck typing gives Python programmers opportunities for great expressive power,
and rapid code development but (some might say) is dangerous because it makes no
attempt to catch type errors.
Some argue that logical errors are far more serious and frequent than type
errors. You need unit tests to catch those more serious errors. So even if you
do do preemptive type checking, it does not add much protection.
This debate lies in the realm of opinions, not facts, so it is not a resolvable argument. On which side of the fence
you sit may depend on your experience, your judgment on the likelihood of type
errors. It may be biased by what languages you already know. It may depend on
your problem domain.
You just have to decide for yourself.
PS. In a statically typed language, the type checks can be done at compile-time, thus not impeding the speed of the program. In Python, the type checks have to occur at run-time. This will slow the program down a bit, and maybe a lot if the checking occurs in a loop. As the program grows, so will the number of type checks. And unfortunately, many of those checks may be redundant. So if you really believe you need type checking, you probably should be using a statically-typed language.
PPS. There are decorators for type checking for (Python 2) and (Python 3). This would separate the type checking code from the rest of the function, and allow you to more easily turn off type checking in the future if you so choose.
You could use a type checking decorator like this activestate recipe or this other one for python 3. They allow you to write code something like this:
#require("x", int, float)
#require("y", float)
def foo(x, y):
return x+y
that will raise an exception if the arguments are not of the required type. You could easily extend the decorators to check that the arguments have valid values aswell.
This is subjective, but here's a counter-argument:
>>> obj = ClassWithThreads("potato")
ValueError: invalid thread count
Wait, what? That should be a TypeError. I would do this:
if not isinstance(num_threads, int):
raise TypeError("num_threads must be an integer")
if num_threads <= 0:
raise ValueError("num_threads must be positive")
Okay, so this violates "duck typing" principles. But I wouldn't use duck typing for primitive objects like int.