Is there any way of preventing runtime errors caused by syntax errors - if
these reside in a piece of code which is not usually executed, testing can
be difficult.
Thanks
Graham
···
--
With Linux, the answer's always "Yes"
Is there any way of preventing runtime errors caused by syntax errors - if
these reside in a piece of code which is not usually executed, testing can
be difficult.
Thanks
Graham
--
With Linux, the answer's always "Yes"
how much code are you writing that you're testing part of it while
other parts aren't even written correctly? (i hope that sentence
makes sense.)
do you use irb? irb is your friend. irb knows all and sees all. irb
has *tab completion*!
-z
On Fri, 9 Jul 2004 19:52:36 +0900, Graham Nicholls <graham@rockcons.co.uk> wrote:
Is there any way of preventing runtime errors caused by syntax errors - if
these reside in a piece of code which is not usually executed, testing can
be difficult.Thanks
Graham
Yeah, if you use the interactive prompt, it would seem that this would
work out for you. Lets you focus on small parts that you want to focus
on.
On Fri, 9 Jul 2004 19:52:36 +0900, Graham Nicholls <graham@rockcons.co.uk> wrote:
Is there any way of preventing runtime errors caused by syntax errors - if
these reside in a piece of code which is not usually executed, testing can
be difficult.Thanks
Graham
--
With Linux, the answer's always "Yes"
--
</michael fivis>
Syntax errors will be found when ruby loads the file. You can get ruby
to check the syntax of a file without executing it using the -c option
to the interpreter.
Finding other errors, such as misspelled method names, is more complex.
The simplest solution is to make sure your automated tests cover all
your code, and not just the most common path.
Paul
On Fri, Jul 09, 2004 at 07:52:36PM +0900, Graham Nicholls wrote:
Is there any way of preventing runtime errors caused by syntax errors - if
these reside in a piece of code which is not usually executed, testing can
be difficult.
Hi,
Is there any way of preventing runtime errors caused by syntax errors - if
these reside in a piece of code which is not usually executed, testing can
be difficult.
I use this construct in a server that I want to keep running
in the event of unanticipated exceptions being raised:
begin
loop {
# main server loop
}
rescue Interrupt, IRB::Abort, NoMemoryError, SystemExit => ex
puts "Caught exception: #{ex} at #{ex.backtrace[0]} - saving and shutting down..."
rescue Exception => ex
puts "Caught exception: #{ex} at #{ex.backtrace[0]} - ignoring and continuing..."
sleep 1
retry
ensure
# program shutdown
end
I put in the "sleep 1" before the retry in case the error
might recur repeatedly - so as not to go in a tight loop
using up 100% CPU and filling up the logfile with
"Caught exception - ignoring and continuing..." messages
at top speed. ![]()
Regards,
Bill
From: "Graham Nicholls" <graham@rockcons.co.uk>
zuzu wrote:
Is there any way of preventing runtime errors caused by syntax errors -
if these reside in a piece of code which is not usually executed, testing
can be difficult.Thanks
Grahamhow much code are you writing that you're testing part of it while
other parts aren't even written correctly? (i hope that sentence
makes sense.)
my programs so far are fairly small - 2-400 lines so far.
do you use irb? irb is your friend. irb knows all and sees all. irb
has *tab completion*!
Was frustrated by the lack of vi command-line editing support . I had
thought that as I had readline, this woudl be in there automatically, but
when I hit escape then k, nothing (or rather the wrong thing) happened. I
guess I need to read the configure options and recompile.
Still, irb wouldn't help catch syntax errors, presumably. The one that
bites me most (not really a syntax error) is when I'm doing something on a
string (read from a file and chomped, say), which fails with no method for
class nil (maybe I should create the method and make it do nothing?) and
the program bombs out.
Graham
On Fri, 9 Jul 2004 19:52:36 +0900, Graham Nicholls > <graham@rockcons.co.uk> wrote:
-z
--
With Linux, the answer's always "Yes"