Re: Try/Catch

new topic     » goto parent     » topic index » view thread      » older message » newer message
DerekParnell said...
jimcbrown said...

By your definition above, I'd argue that these aren't really exceptions - errors, sure, but they're reasonably anticipatible and should be detectable and correctable with an appropriate amount of testing.

How does one know? I certainly do not know what actually triggers the exceptions in these examples. I know the message displayed, but not the underlying cause.

Looking at your examples, the causes seem obvious.

1) Permissions issue or maybe the OS detected corruption and set the filesystem to read-only.

2) Memory corruption in the editor (likely caused by misuse of a pointer somewhere) could cause this. The illegal character issue is anticipatible in any case (someone else might have edited the file with a hex editor and manualyl inserted illegal characters into the file).

3) Power failure lead to the filesystem not being flushed, so it's in an inconsistent state. This lead to the file becoming corrupt. This situation may not be recoverable, but it can certainly be anticipated.

4) Filesystem is full, when the editor tried to write it re-opened the file for writing (which on some OSes truncates the file to empty, deleting the preexisting data) then failed to write anything to the file due to the fullness issue. Simply offer to write the file to another location, or let the user free up some disk space before retrying....

DerekParnell said...

But my issue is that if we rely on recoverability code, then we may be unpleasantly surprised when we happen across situations that cannot be always be recovered.

That's a different, tangential issue that requires it's own topic to discuss.

I do agree that there are cases where the situation is not recoverable. But why should be deliberately handicap ourselves in unanticipatible but recoverable scenarios?

DerekParnell said...

And I didn't even mention what we might try when exceptions happen during the execution of the recovery code.

Ditto.

DerekParnell said...

What we need is a compelling argument for why recovery should be an option after an exception occurs - and what exactly do we mean by recovery?

I said, quite explicitly, that the examples are exceptions, in the sense that the coder used the try-catch paradigm. It actually doesn't matter if they are errors or exceptions, because I was trying to focus on the idea of recover from when things go pear-shaped.

I think, if we can't get the terminology straight, we're going to confuse ourselves talking about apples vs oranges.

You previously defined exceptions to mean unaniticipatble, unrecoverable events. But exception has also been defined as being an object that gets thrown about in the try-catch paradigm. Lets call the former "unrecoverables" or "unrecoverable exceptions" and the latter "Throwables".

So, IIUC you say that your examples are examples of Throwables. I agree. You also seem to be saying that they are also examples of unrecoverables. While I don't entirely agree, I understand the point you are trying to make, so I'll accept this premise for the sake of argument.

So, you gave examples of Throwables and unrecoverables. What's the correct way to interpret this?

DerekParnell said...

What we need is a compelling argument for why recovery should be an option after an exception occurs

"What we need is a compelling argument for why recovery should be an option after a Throwable is thrown"

OR

"What we need is a compelling argument for why recovery should be an option after an unrecoverable occurs"

I think the answer to the former is self-evident. I don't think a compelling argument for the later exists, as the situation is by definition not recoverable. But the latter also has nothing to do with dcuny's original example and use case which lead him to ask about adding try/catch in the first place!

DerekParnell said...

User input errors are not exceptions, in my way of thinking. User input ought to be validated a soon as practicable upon entering the application.

I agree in principle. Actually getting this right is very hard in practice, hence the popularity of try/catch as a crutch.

DerekParnell said...
mattlewis said...

Here's a real life example I run into every day. In my day job, I work with a java project that uses JSF / xhtml markup for building web pages. I use Eclipse. Many of my files include other files. I can select an include statement, hit F3 and have the included file opened in the editor. For some reason, every time I do this, I get a dialog pop up and tell me that there was a NullPointerException. But I can click OK and get on with my job.

It's a bit annoying, and obviously someone has done something wrong here. I've never dug too deeply, but I assume it was the extension / plugin writer who wrote the xhtml stuff. I guess I could find another tool to use or try upgrading or whatever. Or at least report the bug. But...meh...I have better things to do (like get my work done) and at least I can keep working, and whatever that error was, it wasn't critical and was definitely recoverable, though it's a class of error that euphoria would crash upon.

Wow! Not only annoying, but an example of where exception handling is pointless. So someone went to the trouble of catching an exception that has no effect on the job you're doing with the application. Clever.

Why is Throwable handling pointless here? If the Throwable wasn't caught, the IDE would have crashed and taken down all of Matt's unsaved work with it. I don't see this as the preferred outcome.

From the perspective of the IDE writer, it's easy to anticipate a badly written plugin (perhaps still in beta) crashing and throwing a Throwable. But this can be handled - catch the Throwable and maybe disable/unload the plugin. And pop up a message box so the bug can be reported from the user to the developer of the bad plugin.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu