So I got an exception log from my application. I have a call stack, request parameters and all other usual stuff in that log. This is a rare exception and info from the log doesn't contain all details I need to resolve / duplicate the problem.
I wonder if there is some way (gem?) to get full dump of Rails application state in case of an exception. Including all instance and local variables values from a controller methods. I guess that dump of whole Ruby object space might take even a minute or so but I don't care about disk and cpu resources in a such case.
I don't think so, the way I go about trying to do something like that is by using logger.error on the variables that i need more on info on.
If possible, it's also not a bad idea to try running it with ruby-debug (instructions here). All you would need to do is insert a call to debugger right before the error would be triggered or stick it in a rescue clause.
I am unaware of any method to get the application state.
One thing I do upon occassion is install netbeans which has a graphical debugger. You can hover over variables to see their values, easily walk the stack, and also have the exception trigger the debugger, rather than a breakpoint.
Related
I often find myself without knowing what exceptions to rescue when using a specific library of code in Ruby.
For instance, I often use HTTParty for any HTTP requests my rails/sinatra app would make. I dug around the code for HTTParty and found a file containing the defined exceptions used. Great! I'll just rescue them when making a request.
To test it out, I put in a bogus domain name for the request, but instead of HTTParty::ResponseError exception I expected, I instead get got a SocketError exception.
What is the best way to deal with this? I'm aware that HTTParty is a wrapper for Ruby's implementation, and that's probably what threw the SocketError exception. But how would I know that normally?
I could solve this by just rescuing "Exception", but that's pretty awful practice. I'd rather be well aware of the exceptions I could be causing and dealing with those.
EDIT: I should clarify that what really prompted me to create this question was that I have no idea how I can figure out the possible exceptions that CAN be raised when calling a specific function... that is, without looking through every single function call in the stack.
In general terms (I'm not a ruby programmer) I use the following approach.
I deal with exceptions in the following way:
Can I recover from it? If the exception can happen and I know I can recover or retry perhaps, then I handle the exception.
Does it need to be reported? If the exception can happen but I know I can't recover or retry perhaps, then I handle the exception by logging it and then passing it on to the caller. I always do this on natural subsystem boundary like major module or services. Sometimes (dependant on the API) I might wrap the exception with a 'my module' specific one so that the caller only has deal with my exceptions.
Can't handle it? All exceptions that are not dealt with should be caught at the top level and (a) reported, (b) ensure that the system remains stable and consistent. This is the one that should always be there regardless of whether the other two are done.
Of course there is another class of exception - the ones that are so serious that they give you no chance to deal with them. For these there is only one solution -Post Mortem debugging and I find the best thing for this is logs, logs and more logs. And having worked on many system from small to large, I would prefer to sacrifice performance for stability and recoverability (except where it's critical) and add copious amounts of logging - introspectively if possible.
A socketError response is totally fine if you put in a bogus domain name.
After all - trying to connect to a non-existant domain would cause the connection to fail AKA SocketError.
The best way to deal with that is to use a valid Domain with a false URL in your test, but catch socketError in your live code.
The problem here is not that you're catching the wrong exception but that you're priming the test with bad data.
The best course of action is understand what exceptions could happen and manage them,
When I say understand, I'm getting at - Where does the URL come from, is it entered by your user ? if so never trust it and catch everything. Does it come from your config data; Semi trust it and log errors, unless it's mission critical that the URL is ok.
There's no right or wrong answer here but this approach will, I hope, give you a good result.
Edit: What I'm attempting to do here is advocate the mindset of a programmer that is aware of the results of their actions. We all know that trying to connect to 'thisServiceIsTotallyBogus.somethingbad.notAvalidDomain' will fail; but the mindset of a programmer should be to first validate exactly where that domain comes from. If it is inputted by the user then you must assume full checks; if you know it's from a config file only accessed by yourself or your support team; you can relax a little; Sadly though, this is a bad example as you should really always test URLS because sometimes the internet doesn't work!
Ideally, the developer documentation for anything you use should tell you what exceptions that it can throw.
For libraries or gems where the source code is publicly available, you can typically find the types of exceptions in an exceptions.rb file. (Ref here). Otherwise you will have to rely on the documentation. If all else fails you can rescue StandardError, although it is a less-than-ideal practice in many cases (ref this SO answer.
it would be nice to see some additional info about exceptions just in browser. not only exception itself with few lines of code and not necessary (for me during development) stack traces but, for example, sql and, maybe, some more info - like exact place of problem in looong line of code (it is possible, i guess). it would be very helpful to see exact objects (truncated if it would be long) instead of Array:0x00000103e26ea0 in
undefined method `name' for #<Array:0x00000103e26ea0>
even additional info from log would be nice to see right in browser without switching to log every time
any tricks (gems, monkey-patches) on this?
in other words: what do you use to pleasurify (is this word exists?:)) development process?
thanx in advance
In addition to the development log (which includes your SQL errors) you might take a look at Hammertime or Pry, both of which are good debuggers that let you inspect your code more carefully around an exception.
I use the function 'JclGetExceptStackList' to log the call stack of the raised exceptions.
I wish, that if possible to also log the parameters value from the method that raised the exception.
I dont know if is possible to do that with JclDebug, or that exists any other way to do that.
Can anyone help me?
Thanks!
While it's not possible to do it with JclDebug, and while doing it by hand might be a lot of work, you might find that any logging tool, including Log4D, or CodeSite or even outputdebugString, could do it with less work. It will in fact be inserting code to log your parameter calls, in any place where you choose to insert such logging. It can also insert a special marker when an exception is raised, allowing you to reconstruct the exact scenario that lead to your crash.
But since CodeSite doesn't do it only when an exception is going to happen (how would it?) this isn't exactly what you wanted. I do find however, that a reasonable trace log, combined with the jcl stack traceback (or madeexcept or eurekalog) is more than enough and that if I really need to know all the parameter values involved in a call, I should go back and add more trace messages.
That's not possible in general because parameters are typically passed in registers. which are overwritten each time a procedure call is made.
I'm using rhino ETL for the first time in a project, and I'm very
impressed by its capabilities. I use a join-operation to match two
datasources.
Sometimes there might be missing data, so I override LeftOrphanRow to
"log" the error. So I though I would throw an exception and then at
the end of the process collect all occured exceptions using
GetAllErrors().
But as it seems the process is being aborted with the first exception.
Is that intentionally? What would be the best way to deal with
OrphanRows (especially when I would like to have a summary of all orphan rows for all operations at the end of the process)?
Seems to me that the problem is that you're trying to use exceptions to report a non-exceptional event. That's not really what exceptions are for, and certainly when you're expecting the exception to pass through a third-party library, you shouldn't rely on that library to behave in any specific way with respect to that exception.
Can you just keep a list of orphan rows somewhere, e.g. globally, and add to it whenever you encounter one in any of your join operations? Then after your EtlProcess is finished, just print the list out. You might also consider using log4net to accomplish this. Or even simply raising an event, that you subscribe to elsewhere and do whatever seems appropriate.
I've got a program that's having some trouble during shutdown, raising exceptions that I can't trace back to their source. It appears to be timing-related and non-deterministic. This is occurring after all shared resources have been released, and since it's shutdown, memory leaks are not an issue, so that makes me wonder if there's any way to just tell the program to terminate immediately and silently after releasing the shared resources, instead of continuing with the shutdown sequence and giving an exception message box.
Does anyone know how to do that?
After looking at the Delphi Run Time Library source code, and at the Microsoft documentation; I can corroborate Mason and Paul-Jan comments.
The hierarchy of shutdown is as follows
Application.Terminate()
performs some unidentified housekeeping of application
calls Halt()
Halt()
calls ExitProc if set
alerts the user in case of runtime error
get rid of PackageLoad call contexts that might be pending
finalize all units
clear all exception handlers
call ExitprocessProc if set
and finally, call ExitProcess() from 'kernel32.dll'
ExitProcess()
unloads all DLLs
uses TerminateProcess() to kill the process
ExitProcess(0) ?
Halt(0) used to be the good old fashioned way of telling the program to end with immediate effect. There's probably a more Delphi-friendly way of doing that now, but I'm 95% sure halt(0) still works. :-)
In case HeartWare's suggestion of using ExitProcess() fails, it might be you are using some DLL's that do not respond well to the DLL_PROCESS_DETACH. In that case, try using a TerminateProcess( getCurrentProcess, 0 );
Once you resort to such measures, one might wonder if the "cleanly" part of the topic title still holds up to scrutiny.
The last time I had to hunt a problem like this was the shutdown was a causing an event (resize? It's been a while.) to fire on the dying window causing an attempt to redraw something that needed stuff that had already been disposed of.