I've developed a function where i use the return function to spit out a list of vectors. Unfortunately there are still a few bugs in my code. Once my function has failed due to error can i recover that list of vectors?
Functions have their own scope, so if a function fails, the function will exit and no return value will be returned. It's difficult to say what's making your function fail without looking at your code. If the failure is due to something you have control of in your code, I suggest you solve it before relying on potentially function bogus results. But if the failure is out of your control (e.g. calling an unavailable external data source) you can wrap your risky code in a try call to recover in the event of an error. I hope this helps.
Related
First I have a package called DataBaseLayer and it has an S3 method called LoadFromTable(data_request). Second there is another package called RiskCalculator which determines several types of risks and does requests to the database by means of the package DataBaseLayer. Before "triggering" RiskCalculator (by means of an execute function defined in it) a connection to some schema of the database is set up and the method LoadFromTable will refer to that particular schema.
For some tests that I need to perform I have to switch schema depending on the value in data_request that enters LoadFromTable(data_request). Thus what I actually need is to insert a little check in LoadFromTable. As a note, currently there is only a default method implemented, i.e. LoadFromTable.default, and it would thus suffice even to only insert that check in that specific method.
My question is thus twofold:
1. Is there a general way to insert a piece of code before any LoadFromTable method is called, naively said: to insert a piece of code just before UseMethod("LoadFromTable", data_request) is "called".
2. If there is no such way, can we at least insert a piece of code just before LoadFromTable.default is called (for in my case that would now suffice).
As a final note, I can imagine you might say that the whole structure should be changed, and I agree, however, that is not an option for I am not the owner of these packages.
Thanks for your help.
It’s strongly discouraged, and fundamentally the wrong approach, to change code in loaded packages, so I won’t discuss it here (but I’ll mention that this is done via the assignInNamespace function).
But your case can be solved much easier: just override the LoadFromTable generic function in the RiskCalculator package as follows:
LoadFromTable = function (request) {
# TODO: perform your check here.
DataBaseLayer::LoadFromTable(request)
}
Now if you load your RiskCalculator package and call the function either explicitly (via RiskCalculator::LoadFromTable) or implicitly (via LoadFromTable after attaching the RiskCalculator package), your implementation will be called.
Try trace:
library(DataBaseLayer)
trace(LoadFromTable, quote(print("Hello")))
The library statement is important, even if you don't otherwise access that package yourself.
I'm writing a program in Scala and trying to remain as functionally pure as is possible. The problem I am facing is not Scala specific; it's more to do with trying to code functionally. The logic for the function that I have to code goes something like:
Take some value of type A
Use this value to generate log information
Log this information by calling a function in an external library and evaluate the return status of the logging action (ie was it a successful log or did the log action fail)
Regardless of whether the log succeeded or failed, I have to return the input value.
The reason for returning the input value as the output value is that this function will be composed with another function which requires a value of type A.
Given the above, the function I am trying to code is really of type A => A i.e. it accepts a value of type A and returns a value of type A but in between it does some logging. The fact that I am returning the same value back that I inputted makes this function boil down to an identity function!
This looks like code smell to me and I am wondering what I should do to make this function cleaner. How can I separate out the concerns here? Also the fact that the log function goes away and logs information means that really I should wrap that call in a IO monad and call some unsafePerformIO function on it. Any ideas welcome.
What you're describing sounds more like debugging than logging. For example, Haskell's Debug.Trace.trace does exactly that and its documentation states: "These can be useful for investigating bugs or performance problems. They should not be used in production code."
If you're doing logging, the logging function should only log and have no further return value. As mentioned by #Bartek above, its type would be A -> IO (), i.e. returning no information () and having side-effects (IO). For example Haskell's hslogger library provides such functions.
A Promise is an object type which serves as a placeholder for a future result,
such as the body of an HTTP request, or the return value of a Meteor method call.
Basically any function that forces you to pass a callback to recieve its
return value (instead of just returning it) is said to be an async function,
and the value it gives back can be represented by a Promise.
The issue in Meteor is that helper methods are only intended to work with
synchronous values - such as the text in a web page, or the contents of a
Minimongo collection. When you return a Promise from one, the helper
shows [object Promise] instead of the resolved value
does not update when the promise resolves
Some attempts at solving this exist: simple:reactive-method
and arsnebula:reactive-promise, but they require you to change your helpers to a certain style, or only work with Meteor.call instead of just simply allowing a generic promise to be returned.
Is there something existing I've overlooked, or is there a solution in the works? I've been experimenting with this for some time, and may work on something myself if there's not an official answer.
Even with respect to other libraries out there, I think the answer for now is to go with the package deanius:promise (disclaimer: I authored it, with input from the authors of some other packages).
It does what the question asks, and adds some nice touches like controllable error and loading messages.
in my code, i invoke IMediaControl::Run and Pause couple times.
but sometime the function IMediaControl:Run return E_INVALIDARG, that is so wired, the run function has no argument.
can anybody help me about this;)
Most probably, this error code is returned from one of the filters in the graph, and that's being passed back to your app via the graph manager.
I've recently started programming with PHP again, after a long stint with other languages during which i've developed a more functional style - which i'm hoping to try and maintain.
I've noticed some weird behaviour, which I managed to distill into a testcase that I'm hoping someone can explain.
$func = function($item) {
if ($item == 0)
throw new Exception("Can't do 0");
return $item;
};
try {
array_map($func, array(1, 2, 3, 0, 5));
} catch (Exception $ex) {
echo "Couldn't map array";
}
When executing the above code, i see the following output:
Warning: array_map(): An error occurred while invoking the map callback in map_closure.php on line 10
Couldn't map array
I can suppress the error with # on array_map, but this seems hacky at best.
The warning is generated because, put simply, the callback function is not returning normally (due to throwing the Exception). This is just the way that array_map() is coded, if the callback function does not complete its execution. Remember an Exception breaks out of execution immediately, as far as your PHP code is concerned.
As for how to silence the warning, that's entirely up to you. Unfortunately, the warning will be generated and it's your choice to bury it or let it get displayed.
As an aside, maybe your test case was over-simplified but, it would make much more sense to use array_filter() (or perhaps array_reduce()) there.
As preinhaimer says, array_map makes it really hard for you to see exactly what happened during its execution because it predates exceptions. It would not be practical to change its behavior anymore since that would lead to lots of (poorly-coded) applications breaking; that's life.
If you want a mechanism with which to check if the array_map completed without errors or not, I have posted a detailed answer (with code) to this question which deals with practically the same problem. It's not as easy as try/catch, but you work with what you have.
Either use # or a foreach instead of array_map
array_map() predates exceptions so it still uses warnings. There's a few annoying places in PHP where you're still forced to use error handling, this is one of them.
You're left with options like having it return null or some other un-used value when it encounters a problem, or filtering the array to ensure it only contains valid options before you run it through array_map.