Jump to content
bfarber
 Share


IP.Board 3 Error Handling Improvements

It is necessary in any application to handle error situations. The most common method of handling such a situation is to issue an alert to the user so that they know an error has occurred. While this is sufficient in most cases to resolve the problem, we wanted to address IP.Board's error handling routines a little bit with the upcoming release to try to make them a little more useful.

Firstly, we've gone through all of the errors that are issued, and clarified and separated them. No more obscure "Sorry, some required files are missing" error messages when doing something as simple as visiting a topic that has been deleted. The error messages should be much easier for the end user to understand with the upcoming release.

In addition to updating the error messages themselves, we've added unique error codes to each and every message. The error codes follow a defined format so that in the event you need to submit a ticket and reference an error message you received, by providing the error code our technicians can look up more information on the error and easily find where and how it was triggered. This should help make technical support more efficient for all of us.

At some point following the release of IP.Board 3.0, we intend to make public this error codes database so that users can easily look up more information on errors when they need to by themselves.

Further to this, we've added error logging. By default, certain errors will trigger a log to be generated. Generally, these logs are only generated when an error has occurred that could indicate a user is attempting to bypass security restrictions. Some administrators may want to trap more errors, however (perhaps even all generated errors), and as such we've added a setting that allows you to force IP.Board to log all errors above a given level (levels range from 1 through 5). Additionally, you can opt to be notified of all errors triggered above a certain level. For instance, if you want to know about all level 5 (serious) errors encountered right away, you can have the board email you when such an error is generated. This can help you administrate your board more effectively and securely by identifying issues you didn't know existed (for instance, in a custom modification), and can help our technical support drill down on issues that are unique to your site.

The log pruning task has been updated to support the new error log tables so you can prevent it from growing too large.

We have some more ideas for improvements to the error system in general to provide more value and assistance for you and your users. Errors are a necessary part of application development, but we are doing our part to make them as friendly and manageable as possible.

If you have more ideas for improvements to the error management system in IP.Board 3 please share them with us below!

 Share

Comments

Recommended Comments

There is at least one error that I know of which ends with something like "please contact an administrator" (The one I am thinking of is if the uploads folder isn't write-able) - would I be right to assume that if such an error was encountered in 3.0 by default the admin would be automatically notified?
Also, with something like that, it is fairly likely that the user will try again - does the system have something in place so that the admin is only notified once? How is this handled?

Link to comment
Share on other sites

[quote name='PutzMan' date='Sep 16 2008, 09:39 PM']Excellent, I like the sound of the error levels!!! :)

Does this also add a BIT more detail to the IPS Driver Error pages (If they even still exist?)

Probably not, though that will need clarifying. They aren't classed as the same errors, and they actually removed detail from that page for security reasons :)

Link to comment
Share on other sites

Presently, the notifications are based on an error level basis. Many errors require the user to contact an administrator (no permission to access something, folder not writable, etc.) and we don't want to make any automated assumptions on when to send you the email. As such, an admin is not automatically notified of anything.

Link to comment
Share on other sites

[quote name='PutzMan' date='Sep 16 2008, 04:39 PM']Does this also add a BIT more detail to the IPS Driver Error pages (If they even still exist?)

These are not handled through the error system (because we can't guarantee the skin has even been loaded to display an error) but we do have some ideas in mind for this page. :)

Link to comment
Share on other sites

This sounds great, as the current error handling leaves something to be desired.. Having a unique error number for each type of error is good, but PLEASE have human-readable error messages for end users where it would be appropriate. Such as "Sorry, but this topic no longer exists" if a user follows a link to a topic that doesn't exist, instead of the more generic, "Sorry, the link that brought you to this page seems to be out of date or broken." And yes, the "Sorry, some required files are missing" is extremely annoying, so I'll be glad to see that go away. :D

Logging of errors and different error levels are big improvements. As well as email notification of critical errors. Big wins. :)

..Al

Link to comment
Share on other sites

[quote name='iBotPeaches*' date='Sep 17 2008, 03:21 AM']Hopefully a way to filter the amount of errors, like say if someone refreshed and re-threw that error, would you re-get the email?

Thats the only potential error I see.

Otherwise can't wait.

I'm wondering... was that intentional? :lol:

Link to comment
Share on other sites

[quote name='AtariAge']PLEASE have human-readable error messages for end users where it would be appropriate. Such as "Sorry, but this topic no longer exists" if a user follows a link to a topic that doesn't exist, instead of the more generic, "Sorry, the link that brought you to this page seems to be out of date or broken."

Yes, this is already done. That's what I was getting at in the blog entry in the first paragraphs. :)

[quote name='iBotPeaches']Hopefully a way to filter the amount of errors, like say if someone refreshed and re-threw that error, would you re-get the email?

Presently, no. This could be done, but I'm not sure if we will or not. See, my thinking is, you would only want to be immediately notified if there is a critical security error. Some errors triggered by IPB indicate someone is trying to bypass security measures, and you may want to be notified by them. I don't know the value in only sending you one email in these cases. What if someone is trying many different ways to bypass these measures. If I get one email, I might ignore it. He didn't succeed. If I get 10, I'd probably log in to the site to figure out what's going on.

[quote name='Scion']Sounds much more efficient. Would the errors be PMed, emailed, or what?

Emailed. The idea is to notify the admin ASAP, and PMing the admin about the error isn't going to accomplish that in most cases.

[quote name='om']or maybe the "error report" can be sent to the report centre so that the moderators can inform the admin personally incase it needs an admins intervention.

I don't personally see the value in this myself. It would be easy to accomplish, but why store a second copy of the error in separate database tables from the existing error log tables, then have the moderators see this error and notify an admin - instead of just sending the admin an email to begin with.

[quote name='adelx']How about a centralized place inside the ACP, where admins car read the error logs instead of having to use FTP.

Already done. :) Of course, this only applies to IPB error screens, not to SQL error logs or PHP error logs. But these new error logs have a viewer in the ACP.

Link to comment
Share on other sites



Great news. Well done.

I wonder why it is not possible to include other errors (SQL and PHP) in this viewer. It is such a pain to have to use FTP client to check the log file inside the cache folder.

Already done. :)) Of course, this only applies to IPB error screens, not to SQL error logs or PHP error logs. But these new error logs have a viewer in the ACP.

Link to comment
Share on other sites

I suspect that error numbers will be unique to every situation that the error function is called, and you are documenting these numbers. But I have a couple of concerns:

As far as mod authors are concerned, will they be able to do the same? Can it be more than just a number? Like RC27? When you document these numbers, can they be on the IPS resource site? Can you add something to file modifications to include a list of error codes? That way on the resource site when you're presented an error code, you can enter it in and find what modification it is, and where it's being called, and why. And any effort to keep the codes unique would be cool :).

Also in "IN_DEV" mode could you please display output from the debug_backtrace function? That way when an error is called, whether it be permission error or what ever, you know exactly how each function was stepped through (and perhaps what was passed into each function?). That would make debugging and tracking down problems a lot easier.

Also a nice thing to have is to be able to easily restrict "IN_DEV" mode to a specific component rather than globally. Weird things happen when you put the whole board globally into "IN_DEV" mode (like with the skin). Being able to debug a specific module on a live site without effecting the rest of the board would be ideal.

Link to comment
Share on other sites

@adelx

1) PHP errors simply cannot be trapped. It's an error in the PHP code as a whole. Notices and warnings can *sometimes* be trapped, but they're not all that important anyways generally. Unfortunately there's nothing we can do about these.

2) SQL errors can SOMETIMES be trapped, but if the error is (for example) unable to connect to the database, how would we store that error in the database? :huh: As a result these need to be logged to a flat-file. There has been talk of building a viewer in the ACP for these flat files, but nothing has come of that talk as of yet.

@Luke



Same what? Supply an error code when an error is triggered? Of course.



We will only be using integers, however the error log table uses varchar(24) for the column (for this reason), so you are free to use text in the code if needed.



That is where we planned on putting them, once we decide to make them public.



I think this is a bit outside our scope here. ;) We will be documenting error codes that we utilize and providing them. Whether we will support mod authors in some fashion in this documentation in the future is something I cannot guess at this point. Of course our primary concern remains (and will remain) IPB itself, so we'll worry about modifications once IPB is ready to go.

Also a nice thing to have is to be able to easily restrict "IN_DEV" mode to a specific component rather than globally. Weird things happen when you put the whole board globally into "IN_DEV" mode (like with the skin). Being able to debug a specific module on a live site without effecting the rest of the board would be ideal.

IN_DEV mode is a mode that we have for our own sake, which we do not remove when we release the software. If you want to take advantage of it, I urge you to do so. However, we have no need for a backtrace to be printed every time an error occurs and won't likely be adding this in. What you could do if this was critical to you is create a new output engine, copying over the HTML one, and simply making this change yourself in your new engine. Tie all your skins to the new engine and you're done. Won't be overwritten in an upgrade, no modifications to the core code, and you can accomplish whatever you want with the error routine.

As far as mod authors are concerned, will they be able to do the same?

Can it be more than just a number? Like RC27?

When you document these numbers, can they be on the IPS resource site?

Can you add something to file modifications to include a list of error codes? That way on the resource site when you're presented an error code, you can enter it in and find what modification it is, and where it's being called, and why. And any effort to keep the codes unique would be cool original.gif.

Also in "IN_DEV" mode could you please display output from the debug_backtrace function? That way when an error is called, whether it be permission error or what ever, you know exactly how each function was stepped through (and perhaps what was passed into each function?). That would make debugging and tracking down problems a lot easier.



Link to comment
Share on other sites



Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...