Ticket #93 (closed defect: wontfix)

Opened 4 years ago

Last modified 2 years ago

introduce proper error handling

Reported by: ChristianK Assigned to: ChristianK
Priority: major Milestone: 0.3 GUI - Physics - Refactor Release
Component: unspecified Version: svn
Keywords: Cc:

Description

There are many places in Arc where we

  • throw an unqualified Exception or
  • discover a fatal error, log it and just proceed anyway.

As more people start using Arc, we will have to replace these hacks with proper error handling. In most cases this will mean creating a error-specific exception and throwing it.

While we're introducing these changes, we should also have an eye on the exception safety of our code.

Change History

10/03/07 16:34:08 changed by clayasaurus

I say we do both, logging and exceptions.

Logging code in the right places within Arc will be wonderfully useful to both ourselves and the users, in pinpointing the exact place something goes wrong.

We should also probably build an exception hierarchy, something like...

ArcGeneric?

Just so we or the user can properly handle exceptions with Arc.

10/04/07 07:42:47 changed by ChristianK

Logging+Exceptions: Yes. As long as exception stack traces aren't a default feature, that'll be very helpful.

Hierarchy: Hm, I was thinking more along the lines of

  • Exception
    • ...
    • SDLException
      • ImageLoadException
      • ...
    • GLException
      • ...

I can hardly see someone writing: 

try { ... }
catch(ArcWindowException) {

}
catch(ArcSoundException) {

}

Why would you want to treat errors differently depending on which module they originate from? So I wouldn't make the module hierarchy into the exception hierarchy.

SDL and GL exceptions make sense to me since they could carry additional state (like the respective error flag etc.). GUI exceptions would probably also be sensible, but I'm not aquainted with that part of the code.

03/07/08 13:08:16 changed by clayasaurus

Exceptions seem like a pain... I'm kind of tempted to just log fatal errors and proceed anyway.

Since this lib is aimed more at newb's, I also made the logging automatically go to arc.log for every application. That way, when someone has a problem with arc crashing, they can simply post the arc.log file and hopefully there will be a 'fatal' message in there.

I'll have to think about this one a little bit more..

03/07/08 13:15:51 changed by ChristianK

But if an error is fatal, how can we continue anyway?

05/13/08 13:43:55 changed by clayasaurus

  • milestone changed from 0.3 to 2008-2009 Maintainance.

03/05/09 18:16:35 changed by clayasaurus

The application will crash and the user will look at the log.

Scope(exit) can safely close down what we need.

I'll keep the exception handling in mind, but it's not on the top priorities as of now.

03/18/09 14:26:54 changed by clayasaurus

  • milestone changed from 2008-2009 Maintainance to 0.3 GUI Release.

11/03/09 15:02:53 changed by clayasaurus

  • status changed from new to closed.
  • resolution set to wontfix.

For now, don't have time for this kind of work.

Besides, I think that having arclib keep a copious log file is quite handy for tracing arclib's execution and seeing the errors, since D doesn't have to great of a debugger yet (Windows).

So, closing this.