I am struggling a little bit to find a good method for error handling with clientside routing with react-router.
Say I transition from one page to another, and an error occurs when attempting to fetch data (using redial), or something errors while trying to render the components for my page. It doesn't seem like these errors hit the onError function I pass to my Router...
I wasn't able to find much information looking around github issues. Does anyone have a good pattern they like for rendering an error page whenever something unexpected happens on clientside transitions?
Related
When working on a SolidJS project you might start seeing the following warning message in your JS console:
computations created outside a `createRoot` or `render` will never be disposed
There are some information available on this in SolidJS' Github repository issues. But after reading them I was still not quite sure what this was all about and whether my code was really doing something wrong.
I managed to track down where it came from and find a fix for it based on the documentation. So I'm providing the explanation and the solution for those Googling this warning message.
In essence this is a warning about a possibility of a memory leak due to a reactive computation being created without the proper context which would dispose of it when no longer needed.
A proper context is created a couple of different ways. Here are the ones I know about:
By using the render function.
By using the createRoot function. Under the hood render uses this.
By using the createContext function.
The first is by far the most common way, because each app has at least one render function call to get the whole show started.
So what makes the code go "out of context"?
Probably the most common way is via async calls. The context creation with its dependency tree happens only when the synchronous portion of the code finishes running. This includes all the export default function in your modules and the main app function.
But code that runs at a later time because of a setTimeout or by being in an async function will be outside of this context and any reactive computations created will not be tracked and might stick around without being garbage collected.
An example
Let's say you have a data input screen and have a Save button on it that makes an API call to your server to save the data. And you want to provide a feedback to the user whether the operation succeeded or not, with a nice HTML formatted message.
[msg,setMsg] = createSignal(<></>)
async function saveForm(){
...
setMsg(<p>Saving your data.<i>Please stand by...</i></p>)
const result=await callApi('updateUser',formData)
if(result.ok){
setMsg(<p>Your changes were <b>successfully</b> saved!</p> )
} else {
setMsg(<p>There was a problem saving your data! <br>Error: </p><pre>{result.error}</pre> )
}
}
...
<div>
...
<button onClick={saveForm} >Save</button>
{msg()}
</div>
This will produce the above mentioned warning when the API call returns an error, but not the other times. Why?
The reason for this is that SolidJS considers the code inserts inside JSX to be reactive, ie: need to be watched and re-evaluated. So inserting the error message from the API call creates a reactive computation.
The solution
I found the solution at the very end of the SolidJS doc. It's a special JSX modifier: /*#once*/
It can be used at the beginning of a curly brace expression and it tells the SolidJS compiler to explicitly not to make this a reactive expression. In other words: it will evaluated once and only once when the DOM nodes are created from the JSX.
In the above example here's how to use it:
setMsg(<p>There was a problem saving your data! <br>Error: </p><pre>{/*#once*/ result.error}</pre> )
After this there will be no more warning messages :)
In my case, I had an input and when that input changed I re-created an SVG drawing. Because the SVG creation was an expensive operation, I added a debounce in the createEffect function which ran when the input changed. debounce is a technique to defer the processing until the input stops changing for at least X amount of time. It involved running the SVG generation code inside the setTimeout function, thus being outside of the main context. Using the /*#once*/ modifier everywhere where I inserted an expression in the generated JSX has fixed the problem.
I would like to have many devices testing a game, and I find the best way to debug a game and solve specific code problems is to have the device connected and in debug mode in Adobe ANIMATE, that way I can catch any Errors in the Output window.
For Example, if I am debugging and connected to Animate, the output window will throw errors like :
ReferenceError: Error #1065: Variable bg_storage is not defined.
at global/flash.utils::getDefinitionByName()
at Game/stageAdd()[/Users/**/Game.as:360]
Now I know exactly what the problem is and where to find it. I love errors like this.
My question :
If I didn't have a device connected to Animate in Debugging mode, is there a way to make the game detect any errors thrown and store them as a String, that way I can put up a big text block on the game of the error string and keep track.
or at least a way to log them some how?
Ex :
If an error is thrown, have that error text set as a String variable, then have a text box write out that String variable.
I hope that isn't too confusing. If I am going about debugging in a poor way, I would love to know what you guys do to keep track of errors without being connected to debug mode.
EDIT
I can see an approach is you to add an uncaughtErrorEvent event to each function to be able to catch these errors...
loadbar.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR ... )
I am trying to make it so any error thrown in any part of the game will trace that error somewhere to a String value that I can call, so that I can see any error thrown during a play test session without being connected to debug mode.
Thanks!
Sure. There's a class intended exactly for that: https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/UncaughtErrorEvent.html See examples at the bottom of the page to listen to the right instances for that event.
You are also free go grab my own class that does the thing you want: https://bitbucket.org/thydmitry/ru.delimiter/src/2756fadd741a6d44276fde1701470daf24cebfa8/classes/ru/delimiter/utils/Log.as?at=default&fileviewer=file-view-default
You will need to add it to your project and then call in the main document class (in constructor, preferably):
Log.create(this);
Log.handleExceptions(this, true);
Today I was designing the error handling statergy for a new website. I have gone through all the docs for ColdFusion Excepiton
handling.
Now I have some doubts.
What the best solution for handling 404 errors?
Using onMissingTemplate() method
Sitewide Missing Template option(CFAdmin)
IIS custom 404 error handler.
What is the best solution for exception handling?
What should I use for error logging onError() method or Site-Wide Error handler? Is there any significant difference between
these two?
Do I need to use try/catch block for each and every query that I write?
Because there are some queries where I am sure the query will only fail when the database will fail. So if the database fails ,there is no meaning process the page further using try/catch. What should I do in these situations?
I know this question looks bit subjective , but I can not find a better place than StackOverflow for this.
For handling 404's, its better to handle it at webserver level.
For Sitewide Missing Template, you can specify the same in CF Admin. Ensure that the Sitewide error handler file location, should be relative to CF webroot and not webserver root. The dependent files may be put at the webserver.
Please refer to http://blogs.coldfusion.com/post.cfm/onmissingtemplate, for IIS custom 404 error handler. This recent blog post has a detailed description of 404 and error handling.
The answer is that you should use all three.
onMissingTemplate() is application-specific (remember that you can have multiple applications on a single CF instance).
Missing Template Handler is CF-instance specific.
IIS custom 404 error handler works for non-CF files (e.g., .htm, .html, etc.). You can still, of course, specify a CF template as the custom error handler.
FYI, the application-specific onMissingTemplate() method takes precedence over the CF Admin Missing Template Handler. The latter fires if there isn't an application-specific onMissingTemplate().
As far as exception handling is concerned, that is going to depend on a number of factors, but again a multi-layered approach is good.
I'm using View Composers and nested views in general to build my layouts, and whenever any PHP errors are encountered, it always shows a generic Method Illuminate\View\View::__toString() must not throw an exception error message. Is there a way for it to show the actual error without having to guess what it is? Or is this limitation of PHP impossible to get around?
The error log also shows the same vague message, so that isn't a solution either.
I’m struggling fully understanding when/how exceptions are thrown in JSF 2.0. I’ve looked for a solution longer than I care to admit. Ultimately, the goal I want to achieve is “handle” an unhandled exceptions. When an exception is thrown, I want to be able to capture information of interest about the exception, and email that to the appropriate site administrators. I’m forcing an error by throwing a new FacesException() in the constructor of one of my backing beans. I had this working great in JSF 1.1 using MyFaces implementation. I was able to get this working by wrapping the Default Lifecycle and simply overriding the execute() and render() methods. I followed this awesome post by Hanspeter to get that working:
"http://insights2jsf.wordpress.com/2009/07/20/using-a-custom-lifecycle-implementation-to-handle-exceptions-in-jsf-1-2/#comment-103"
I am now undergoing a site upgrade to JSF 2.0 using Mojarra’s. And things work great still as long as the exception is thrown/caught in the execute() method, however; the moment I enter the render(), the HttpServletResponse.isCommitted() equals true, and the phase is PhaseId RENDER_RESPONSE which of course means I can’t perform a redirect or forward. I don’t understand what has changed between JSF 1.1 and 2.0 in regards to when/how the response is committed. As I indicated, I had this working perfectly in the 1.1 framework.
After much searching I found that JSF 2.0 provides a great option for exception handling via a Custom ExceptionHandler. I followed Ed Burns’ blog, Dealing Gracefully with ViewExpiredException in JSF2:
"http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2"
As Ed indicates there is always the web.xml way by defining the tag and what type of exception/server error code and to what page one wants sent to for the error. This approach works great as long as I’m catching 404 errors. One interesting thing to note about that however, is if I force a 404 error by typing a non-exsitant URL like /myApp/9er the error handler works great, but as soon as I add “.xhtml” extension (i.e. /myApp/9er.xhtml) then the web.xml definition doesn’t handle it.
One thing I noticed Ed was doing that I hadn’t tried was instead of trying to do a HttpServletRespone.sendRedirect(), he is utilizing the Navigationhandler.handleNavigation() to forward the user to the custom error page. Unfortunately, this method didn’t do anything different than what Faclets does with the error by default. Along with that of course, I was unable to do HttpServletResponse.sendRedirect() due to the same problems as mentioned above; response.isCommitted() equals true.
I know this post is getting long so I will make a quick note about trying to use a PhaseListener for the same purposes. I used the following posts as a guide with this route still being unsuccessful:
"http://ovaraksin.blogspot.com/2010/10/global-handling-of-all-unchecked.html" "http://ovaraksin.blogspot.com/2010/10/jsf-ajax-redirect-after-session-timeout.html"
All and all I have the same issues as already mentioned. When this exception is thrown, the response is already in the committed phase, and I’m unable to redirect/forward the user to a standard error page.
I apologize for such a long post, I’m just trying to give as much information as possible to help eliminate ambiguity. Anyone have any ideas/thoughts to a work around, and I’m curious what might be different between JSF 1.1 and 2.0 that would cause the response to be committed as soon as I enter the render() phase of the Lifecycle.
Thanks a ton for any help with this!!!
So this question is actually not just about a custom exception handler (for which JSF 2 has the powerful ExceptionHandlerFactory mechanism), but more about showing the user a custom error page when the response has already been committed.
One universal way to always be able to redirect the user even if the last bit has already been written to the response is using a HttpServletResponse wrapper that buffers headers and content being written to it.
This does have the adverse effect that the user doesn't see the page being build up gradually.
Maybe you can use this technique to only capture the very early response commit that JSF 2.0 seems to do. As soon as render response starts, you emit the headers you buffered till so far and write out the response content directly.
This way you might still be able to redirect the user to a custom error page if the exception occurs before render response.
I have successfully implemented a filter using response wrapper as described above which avoids the response being commited and allows redirection to a custom page even on an exception in the middle of rendering the page.
The response wrapper sets up its own internal PrintWriter on a StringWriter, which is returned by the getWriter method so that the faces output is buffered. In the happy path, the filter subsequently writes the internal StringWriter contents to the actual response. On an exception, the filter redirects to an error jsp which writes to the (as yet uncommitted) response.
For me, the key to avoiding the response getting committed was to intercept the flushBuffer() method (from ServletResponse, not HttpServletResponse), and avoid calling super.flushBuffer(). I suspect that depending on circumstances and as noted above, it might also be necessary to also override some of the other methods, eg the ones that set headers.