Alex, now that you've made your example clear by providing examples of the problem (rather than posting the core file), it's fairly straightforward to see the error.
In the first example (as expected) everything is alright. In the second example, you are referencing a circuit which does not exist. The official core file does not define what to do for undefined circuits -- that is not a bug at all, it is a short-coming in the implicit specification. It's actually a *user* error for calling a undefined circuit -- the fact that the core file ends up barfing on it only serves to show that the developer would need to (a) remove typos from the URLs, or (b) pre-process the fuseaction or (c) use one of several other solutions published on the process (for example, the Techspedition core file catches undefined circuits and throws them up to the "home" circuit for handling -- however this doesn't have to be done via a core file, obviously). One thing you should be able to do, although not with the official core file version 3.01, is to compare "fusebox.circuit" with "fusebox.targetcircuit", which would only have differing values in the situation you describe of an non-existing or ill-defined circuit. This test is not necessary in the core file itself, but it is necessary for the core file to set appropriate values for those two API variables (right now targetcircuit is always set to circuit whereas it should have a single conditional applied to it wherein it is set to circuit only after a successful 'does "circuit" exist?' conditional). That is a known problem. In your third example, a empty string fuseaction, again it is not the core file's problem at all. The implicit spec just doesn't define what to do with a fuseaction that has no value. However, the purpose of the fbx_settings file is to set values and if you follow the common practice to put a <cfparam name="attributes.fuseaction" default="corefilestest1.welcome"> in your top-level fbx_settings file then you wouldn't encounter this error. (there are two other such solutions as well -- you can put this above line in the "index.cfm" before the core is even called, or alternately you can make use of the literal fuseaction ".defaultfuseaction".) you'd also asked: > Sorry. I didn't understand you thought of using third party > solutions for error handling. Why I need to use them if I > can make my one in a minute or two? well there are a number of reasons for that. The errors above would have been caught by any trivial error handler, but the real issue is distinguishing between outright errors in the core file (such as the discrepancy between "fusebox.circuit" and "fusebox.targetcircuit") versus errors that occur due to developer mistake or oversight which are only caught later on in the core file (such as that same example). The fact that the error doesn't manifest itself until line X, doesn't mean there is a problem with the core file *at* line X. And, in your third example where you didn't have a default fuseaction defined, that also is not something "wrong" with the corefile at line X; all of the FB3 documentation clearly states how to handle a "default" fuseaction. There is a good argument for having NO error handling of any type in the core file -- just throw the darn error and let the developer deal with it -- as long as a mechanism for identifying the actual source of the error can be found. [Again, I'm not talking about bugs in the core but rather in errors that occur simply during the core file's execution when operating on developers' code.] The third party solutions currently come in two flavors. If you use FEX, then that focuses directly on error handling and one uses a modified core file. If you use Techspedition's FuseQ, then that too uses a modified core file but not for error handling -- the error handling is just one of many solutions that derive from it, some others being bubbling of the error handling, layout fuses, component content, locating circuits anywhere on the physical drive (not just "beneath" the root) and a very easy transition to the Model-View-Controller design pattern popular in the Java world. Either way, the point is that the core file itself needs to be fairly tight and constrained. The larger it is, the more has to be made backwardly-compatible and the more "fragile" it is moving forward. You can most certainly "roll-your-own" error handling but I suspect that it will have to be fairly limited in scope within the constraints of the official core file. That is, it may only take, as you say, a "minute or two" to create an error handler for one particular problem but I feel pretty confident that it would take way more than a minute to conceive and implement a general error handling solution, something more substantial than wrapping the core file in a cftry/cfcatch.. That part is up to you, though. You can always write your own core file, but then you'd be up against the maintenance and compatibility issues which may or may not be something you want. And it also inhibits one's ability to get help with various issues in the public forum since others will not be familiar with the extensive nature of a private core file and would have little incentive for climbing that learning curve to get to the point where they could help you with what is a non-general solution. Going down the custom core file road is a decision each developer has to make on their own. It sounds fun but it's actually a big pain in the butt. My suggestion is that if you're modifying the core file to solve a specific solution by then you're doing it for the wrong reason -- that is "coding by exception" -- and it is often characterized by a series of <CFIF>s. If what you modify solves the specific solution as part of a generalized problem topology, which is manifested by other, unexpected solutions that flow naturally out of it, then it's worth pursuing in some form, either on your own or in working with the authors of one of the core files. ----- Original Message ----- From: "Alex Puritche" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 06, 2002 5:37 AM Subject: Re[2]: Bug in core files? > John, > > I'm not going to post any kind of "live" urls. > I use standard fusebox files. I mean I used them before > yesterday. I'm not sure that screenshots I already posted don't > make sense about the problem. It is definitely a bug, and must be > fixed in future builds of FB core files. > But I wrote sample application. > http://www.new.iname.md/reader/fb/fbtest1/ > I hope it will eliminate all misunderstandings. :-) > > Sorry. I didn't understand you thought of using third party > solutions for error handling. Why I need to use them if I > can make my one in a minute or two? > > Another issue coming soon. ;-) > > > Thursday, June 6, 2002, 3:17:53 AM, you wrote: > > John> Hi Alex, > > John> I'm not sure that really points out any problems at all, there are a number > John> of things that a developer can set up wrong which the core files don't end > John> up catching the error correctly. While that points to the need for better > John> error *handling* with the core files (something you can get immediately by > John> using either the Techspedition or the FEX unofficial solutions, available at > John> www.techspedition.com or www.fusiam.com, respectfully), it doesn't really > John> clear up where the problem is coming from. Can you give us an online URL > John> along with some of your own code ("I tried to log in with fuseaction > John> "users.login" and it threw an error!" or stuff like that) so that we can > John> first determine if you're doing "standard" Fusebox? Otherwise we may well > John> spend multiple man-hours tracking down the problem only to find out it had > John> nothing to do with the core file -- other than in CATCHing the error. > > John> Of course, that is the nice thing about using standardized core files -- you > John> get a much larger group of people who can potentially help you catch your > John> bug because they don't have the learning curve of wondering how your core > John> file works -- cuz it's one of the standard ones! :) SO more people having > John> to use less effort to stomp your bug means a greater likelihood that you'll > John> get help fast. > > > > > John> ----- Original Message ----- > John> From: "Alex Puritche" <[EMAIL PROTECTED]> > John> To: <[EMAIL PROTECTED]> > John> Sent: Wednesday, June 05, 2002 5:54 PM > John> Subject: Bug in core files? > > > >> Hi, folks! > >> Several urls :-) > >> > >> http://www.new.iname.md/reader/fb/was.png > >> http://www.new.iname.md/reader/fb/now.png > >> > >> Can somebody explain me what happening? Do I use "old" set of core > >> files? Or is it just a bug? > >> > >> Explanation for those who can't dig in... > >> fusebox.suppressErrors flag won't work for the "SECTION EIGHT" because > >> this section don't handle it. > >> > >> Several other issues coming soon. :-) > >> > >> > >> -- > >> Regards, > >> Alex mailto:[EMAIL PROTECTED] > >> > >> > > > > -- > Regards, > Alex mailto:[EMAIL PROTECTED] > > ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
