Quite often I process data in Julia and don't want it to crash it, so I use try-catch block. But I'm also debugging it in REPL and then I actually want to kill the block if I see it's doing something wrong.
So far my solution is
for i in <some big loop>
try
do_job(i)
catch e
e isa InterruptException && rethrow(e)
#warn "job failed" i e
end
end
but it does not feel very idiomatic. Is there something better?
I saw this 7 years old question https://github.com/JuliaLang/julia/issues/4037 but it still seems unsolved.
Related
Is there a Goto statement in Halcon? I was not able to find it in the documentation. What I would need is to jump back about 50 lines of code in a certain condition.. Since it happens rarely I'd like to avoid doing it with a loop. Is there a goto statement or something similar that allows me to jump back to a previous point in the same procedure?
No there is not the GOTO statement.
The reason can be: "Code that relies on goto statements is generally harder to understand and to maintain than code without gotos. Although we are not dogmatic about the matter, it does seem that goto statements should be used rarely, if at all." (Brian Kernighan & Dennis Ritchie, The C Programming Language)
https://en.wikipedia.org/wiki/Goto
Does Ada/GNAT supports something like the automatic tracing of the execution of a program (or selected packages/procedures/functions) for debug purposes? I am not interested in a logger package.
Imagine working on a real old Ada project and using a debugger to step through the code is not an option. In my opinion adding text outputs often helps to understand the code:
if A and B or C then
Ada.Text_IO.Put_Line ("1");
[...]
else
Ada.Text_IO.Put_Line ("2");
[...]
end if;
But adding such text outputs is a manual process and it takes time to do it on complex code.
You might want to have a look at rr. I've never used it myself, but it might very well work with Ada.
We have a web application based on asp.net 1.1. We deployed it on a web server but there is a problem about it.
In the webserver sometimes cpu usage is increasing to 100% and outofmemory exception is occuring.
I think there are some wrong code inside the project but i don't know where it's.
Now, i want hear your advices about how to find problem and what kind of codes make cpu usage increased.
it looks like the garbage collector is not doing its work as supposed for some reason. i suggest to look in the code where you have variable declarations inside long loops. for example you need to check for loops that look like this:
dim c as car
for i as integer = 0 to 20
c= new car
c.brand=""
Next
the above loop creates a lot of garbage so make sure to call dispose() when you finish using an object.
another issue to check for is recursion. if you have recursive calls, make sure to check that the breaking condition is correct and make sure to call dispose() too before jumping in the next recursion.
If you have no idea how to debug something once it's deployed, the first place you should look to learn is Tess Ferrandez's blog. Click, and read. A lot. :) May I suggest you start with the debugging labs.
I just read this question, and a solution states that:
The fact that you don't know you got
the NO_DATA_FOUND exception suggests
that you have made one of the biggest
errors PL/SQL developers ever make:
EXCEPTION
-- Never do this in real code!!!
WHEN OTHERS THEN NULL;
END;
Could you explain me what is the error in this statement and what would you do to avoid doing that...
The problem is, that you are catching all exceptions, and then ignoring them. You'll never know when something went wrong.
There's nothing wrong with this snippet of code if you don't want the pl/sql block's exception to propagate any further for example. If you do it on purpose, it's not bad code or a mistake. That's the catch all in pl/sql. And there might be situations in code where you have nested BEGIN/EXCEPTION/END blocks and one might not want the transaction to fail just if a particular cross section of code fails. You can't state it's bad coding if you do it intentionally for whatever reason/requirement.
BEGIN
--something important here
--something even more important here
BEGIN
--something secondary goes here but not important enough to stop the process or
--log a message about it either
--maybe send an informative email to the support group or
--insert a log message when debugging the process or
--the list could go on and on here
EXCEPTION
--I don't care if this block fails, absorbing all errors regardless of type
WHEN OTHERS THEN NULL;
END;
-- something super important here, must happen
EXCEPTION
WHEN NO_DATA_FOUND THEN
-- do something useful for this exception
WHEN OTHERS THEN
-- do something by default if we don't expect this error
END;
It is ALWAYS bad coding. And you can say that it is bad coding if you do it on purpose. In fact, it is horrible code if you do it on purpose because it demonstrats how little you understand about all of the errors you are completely ignoring.
http://stevenfeuersteinonplsql.blogspot.com/2017/02/now-not-to-handle-exceptions.html
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1155066278457
This question already has answers here:
Closed 14 years ago.
This question is a duplicate of Goto Still Considered Harmful. If you wish to discuss this further please use the original question.
Why exactly is GOTO poor programming practise? It makes sense on some occasions to use it.
Note that Djkstra wrote "GOTO Considered Harmful", not "GOTO Considered Deadly". It has its places. Unfortunately, the judgement to know when to use it comes after you've got some experience in maintaining other people's code, especially code that was written years ago by people who no longer work in your company. Thus, it's best to avoid goto as much as you can until you have that experience.
It encourages bad coding style, basically. See: Goto Considered Harmful [pdf]
It can rapidly lead to spaghetti code.
It means you haven't designed the code procedurally.
If you build your whiles and ifs properly, you should rarely ever need goto.
Rarely is the key word. There are times where it's useful. In that sense, many people nowadays just explicitly throw and catch exceptions, just to avoid the dreaded goto.
Because the structure of the code can be difficult to follow.
This
y:
// do more stuff
goto x
p:
// do stuff
// then done
goto y;
x:
// do a bunch of stuff
if (...)
goto y;
else
goto p;
done:
is much less clear than
int main()
{
x();
}
function p()
{
if (...)
{
return;
}
}
function x()
{
if (...)
{
return;
}
else
{
p();
}
}
GOTO short circuits your control flow, thereby undermining your design and opening the door to debug and maintenance nightmares.
Readability becomes a problem, and flow of logic can have unintended effects by the use of goto.
I think its funny that the .net compiler will change some case/switch statements to use goto.
In some cases it makes sense. But, in the majority of cases use of it it considered poor practice because it can make the execution path of code tricky to read compared to using structured code such as for loops and while loops.
When you look at a goto or a label, you don't really know where is goes to or comes from without reading or searching through the code for the label name. This is tricky especially if the goto doesn't fit on the same screen as the label. Compare this to a for loop or a while loop or an if.. you can tell from the structure (i.e. indenting of the code) what the execution path is.
Having said this, it sometimes is useful, especially for example when jumping out of some nested for loops that are digging for a particular value inside a multi-dimensional array. You could use a goto here to jump out of the for loops when the correct value is found.