Makoto Posted November 16, 2015 Posted November 16, 2015 I've spent a good deal of time trying to get the Wizard helper to work correctly in a new application I'm building. A lot of wasted time was caused by this, The error here is not that no file was provided in the above field. This is the error that always ends up being displayed for me when an exception is thrown anywhere during the Wizard's code execution. So, this was the actual issue here, which I managed to trace down after a lot of die(var_dump())'ing, since the Wizard had no means of providing a real traceback to the issue, There was a very minor oversight in the above code, which should have been easily identifiable. The favicons static method was not returning its results, and when the reset static method was being called, it ended up resulting in an error (as the method was trying to iterate over NULL instead of an array). It's a simple issue, but these things are a huge pain and inconvenience to trace down by hand. On top of the above, I recently ran into another issue caused by something also minor. In one of my classes, I have the following setter method, /** * Set the favicon file path and automatically assign the width / height attributes * * @param \IPS\File $file * @return void */ protected function set_file( \IPS\File $file ) { $this->_data['file'] = (string) $file; $this->_file = NULL; $image = \IPS\Image::create( $file->contents() ); $this->width = $image->width; $this->height = $image->height; } In another part of my code, I was still assigning the file attribute with (string) file (i.e. assigning the file path directly), which resulted in an ambiguous "4096" exception being thrown, again with no traceback or discernible debugging information. I've found this seems to happen a lot. Silent errors result in huge headaches and a lot of time wasted digging through various bits of code (at times including code in the core framework), just to try and trace the source of a single issue. This is especially true in themes. I don't really have any immediate suggestions to provide here, this is just to document some of the headaches the above issues have caused me and something I'd really like to see improved in the core framework over time.
Mark Posted November 16, 2015 Posted November 16, 2015 For the wizard: try disabling JavaScript when trying to debug things which involve complicated JS like wizards or multiple redirects. Their no-JS fallbacks are usually able to give much more useful error messages. For the uncaught exception: are you in developer mode? If so, the trace should have been shown on the screen.
bfarber Posted November 18, 2015 Posted November 18, 2015 Further, uncaught exceptions are logged to the System Log (use the ACP live search to look for "System Log") whether in developer mode or not.
Makoto Posted November 18, 2015 Author Posted November 18, 2015 40 minutes ago, bfarber said: Further, uncaught exceptions are logged to the System Log (use the ACP live search to look for "System Log") whether in developer mode or not. I do reference the system log when in production, but I do have developer mode enabled on this installation. It seems tracebacks aren't being properly reported in some cases, but they are usually logged. I'll try and track down the issue and the steps to reproduce the problem so I can file a bug report on it if it's not an issue just with my setup.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.